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FOREWORD 


The  Armored  Forces  Research  Unit  of  the  U.S.  Army  Research 
Institute  for  the  Behavioral  and  Social  Sciences  (ARI)  investi¬ 
gates  training  requirements  for  the  future  integrated  battlefield 
using  soldier-in-the-loop  simulation.  Research  under  this  pro¬ 
gram  is  supported  by  Memoranda  of  Understanding  (MOU)  with  (a) 
the  U.S.  Army  Armor  Center  and  Fort  Knox,  Subject;  Research  in 
Future  Battlefield  Conditions,  12  April  1989,  and  (b)  the  U.S. 
Army  Tank -Automotive  Command  (TACOM) ,  Subject:  Combat  Vehicle 
Command  and  Control  (CVCC)  Program,  22  March  1989. 

The  CVCC  research  program  investigated  advanced  digital  and 
thermal  technologies  to  enhance  mounted  forces'  command,  control, 
and  communications  (C^)  capabilities.  The  CVCC  system  integrates 
a  variety  of  digital  features— report  preparation  and  management, 
tactical  map  and  overlays,  transmission  of  reports  and  overlays— 
with  positioning/navigation  functions  and  independent  thermal 
viewing  for  unit  and  vehicle  commanders.  The  system  also  pro¬ 
vides  digital  C^  capabilities  for  workstations  in  a  tactical 
operations  center  (TOC)  digitally  linked  to  vehicle-based  CVCC 
systems . 

This  Research  Product  describes  and  documents  the  software 
empowering  the  futuristic  c’  capabilities  derived  under  CVCC. 
Documentation  is  provided  in  the  context  of  the  simulated  combat 
systems  and  operations  used  for  CVCC  company,  battalion,  and  TOC 
evaluations.  The  research  and  development  nature  of  the  CVCC 
program  enabled  iterative  development  of  a  genuinely  user-based 
software  product.  This  software's  modularity  and  compatibility 
with  varying  users'  operational  and  experimental  requirements  are 
exemplified  in  the  catalog  of  CVCC  software  switches  that  support 
rapid  tailoring  of  the  C^  features  developed.  Directions  for 
future  architecture  development  are  reflected  in  the  catalog  of 
change  requests  derived  from  user-based  assessments. 

This  CVCC  software  architecture  benchmarks  many  of  the  user- 
based  features,  derived  in  an  operational  setting,  the  Army  will 
require  for  future  automated  C^  systems.  In  fact,  varied  devel¬ 
opmental  efforts  conducted  by  the  Mounted  Warfare  Battlespace  Lab 
(MWBL) ,  TACOM,  and  System  Training  and  Integration  Command 
(STRICOM)  have  already  obtained  and  utilized  CVCC  software  in 
simulation  research. 


EDGAR  M.  JOHNSON 
Director 
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PREFACE 


The  work  described  in  this  overview  was  originally  conducted 
under  the  SIMNET  program  and  subsequently  under  the  Combat  Vehi- 
cle  Command  and  Control  (CVCC)  program  sponsored  by  the  U.S.  Army 
Research  Institute  for  the  Behavioral  and  Social  Sciences  (ARI) , 
Armored  Forces  Research  Unit  (AFRU) ,  was  continued  under  the 
umbrella  of  the  Advanced  Distributed  Technology  (ADST)  program. 

SIMNET  was  an  advanced  research  project  sponsored  by  the 
Defense  Advanced  Research  Projects  Agency  (DARPA) ,  in  partnership 
with  the  U.S.  Army,  from  1983  to  1991.  The  goal  of  the  program 
was  to  develop  the  technology  to  build  a  large-scale  network  of 
interactive  combat  simulators.  This  simulated  battlefield 
provided,  for  the  first  time,  an  opportunity  for  force-on-force 
engagements  against  opposing  units  of  similar  composition. 

Several  core  technologies  were  exploited  in  the  SIMNET 
program  to  achieve  a  breakthrough  in  the  simulation  of  forces  and 
permit  the  use  of  such  simulations  in  assessing  the  training 
impacts  of  the  application  of  advanced  components  to  armored 
combat  vehicles.  The  technologies  permitting  this  advance  are 

•  high-speed  microprocessors 

•  parallel  and  distributed  multiprocessing 

•  local-area  and  long-haul  networking 

•  hybrid  depth  buffer  graphics 

•  special-effects  technology 

•  unique  fabrication  techniques 

These  technologies,  applied  in  the  context  of  "selective 
fidelity"  and  "rapid  prototyping"  design  philosophies,  enabled 
SIMNET  development  to  proceed  at  an  unprecedented  pace  and 
allowed  the  early  adaptation  of  the  SIMNET  research  results  into 
the  CVCC  program  by  the  AFRU. 

The  thrust  of  the  research  conducted  by  the  AFRU  has  been  to 
apply  SIMNET  technology  in  the  area  of  training  and  combat  devel¬ 
opments  to  aid  in  the  definition  and  development  of  requirements 
for  future  weapon  components  and  systems.  This  research  thrust 
is  feasible  because  of  the  relative  ease  with  which  the  tank 
simulators  can  be  modified  in  order  to  place  a  candidate  system 
in  a  simulation  of  the  combined-arms  setting  in  which  it  is  to  be 
used  and  to  interface  its  use  by  soldiers  who  would  be  called 
upon  to  operate  the  system  in  the  real  world.  The  CVCC  program 
is  an  example  of  such  work. 
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The  CVCC  program  is  a  United  States-German  bilateral 
research  and  development  effort  sponsored  by  the  U.S.  Army  Tank- 
Automotive  Command  (TACOM)  to  develop  command,  control,  and 
communications  (C3)  systems  and  hardware  for  future  armored 
fighting  vehicles.  As  part  of  this  effort,  CVCC  is  conducting 
research  into  the  technology  for  a  fully  automated,  integrated, 
and  interoperable  C3  system  for  ground  combat  vehicles.  The  C3 
system  is  intended  to  serve  units  at  battalion  level  and  below 
and  to  link  adjacent  units  and  cross-attached  units. 

The  CVCC  program  was  organized  as  four  teams,  each 
addressing  a  particular  subject  area.  Team  1  was  the  Data 
Elements,  Operational,  and  Organizational  Concepts  Team;  it  was 
chaired  by  the  Directorate  of  Combat  Developments,  U.S.  Army 
Armor  School.  Team  2  was  the  Communications  Team,  chaired  by  the 
U.S.  Army  Communications-Electronics  Command.  Team  3  was  the 
Soldier-Machine-Interface  and  Simulation  Team,  chaired  by  the 
AFRU.  Team  4  was  the  Vehicle  Integration  Team,  chaired  by  the 
U.S.  Army  Tank -Automotive  Command  (TACOM).  The  efforts  of  the 
four  teams  are  interdependent  and  mutually  supportive. 

Under  the  auspices  of  Team  3,  the  Future  Battlefield 
Conditions  Team  of  the  AFRU  conducted  a  series  of  evaluations 
systematically  evaluating  the  various  capabilities  provided  by 
advanced  technologies,  both  digital  and  thermal,  utilized  in 
components  simulating  near  real-time  acquisition,  processing,  and 
dissemination  of  information  providing  digital  map  functions; 
digital  message,  reporting  and  overlay  capabilities;  automated 
navigation  features  (including  a  separate  display  for  the  vehicle 
driver) ;  thermal  viewing  (with  an  integrated  laser  gunner's 
sighting  system) ;  and  system-coupled  digital  battalion  tactical 
operations  center  workstations  for  command,  operations,  and 
planning. 

To  conduct  evaluations  of  digital  and  thermal  advanced 
technologies  there  were  two  areas  of  the  simulation  network 
modification  of  the  simulators  incorporating  a  simulated  command 
and  control  display,  a  simulated  commander's  independent  thermal 
viewer,  and  a  simulated  driver's  steer-to  display  and,  second, 
software  modification  and  development  to  simulate  the  technol¬ 
ogies  to  be  evaluated. 

The  physical  modifications  made  to  the  simulators  were 
accomplished  by  the  Mounted  Warfare  Test  Bed  (MWTB)  site  staff 
and  consisted  of 

•  Mounting  a  13”  color  monitor  at  the  commander's  station 
to  accommodate  the  commander  control  display  (CCD) . 

•  Mounting  a  10”  monitor  and  control  panel  at  the  comman¬ 
der's  station  to  simulate  the  Commander's  Independent 
Thermal  Viewer  (CITV) . 
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•  Mounting  a  flat  panel  display  at  the  driver station  to 
simulate  the  Driver's  Steer-To  display. 

•  Modifying  and  developing  software  evolved  over  the 
entire  series  of  evaluations  conducted  under  the  CVCC 
program.  As  the  research  progressed,  lessons  learned  in 
the  earlier  portions  of  the  research  were  incorporated 
at  each  iterative  step  in  the  program. 

As  progress  was  made  there  are  three  major  principles  that 
guided  the  software  department: 

•  Software  was  developed  in  modular  fashion.  This  was  a 
lesson  learned  early  in  the  program  and  highly  suggested 
for  future  efforts  in  the  simulation  facility. 

•  Soldier-Machine  Interfaces  (SMIs)  were  progressively 
modified  based  primarily  on  soldier  participant  comments 
in  each  iterative  phase  of  the  research. 

•  Iterative  review  of  software  functionality  and  inter¬ 
faces  by  researchers  and  subject  matter  experts  (SMEs) 
were  conducted  prior  to  installation  of  the  software  for 
the  evaluation  process. 

•  As  explained  in  the  body  of  this  document  certain 
software  used  early  in  the  research  process  was  embedded 
in  the  tank  simulator  software.  It  became  apparent  as 
the  research  progressed  that  it  was  much  more  useful  and 
feasible  to  develop  the  experimental  simulation  software 
in  functional  modules.  The  CITV  software  developed 
early  in  the  program  is  embedded  with  the  tank  simulator 
software.  Later  software  developed,  such  as  the  CCD  and 
the  tactical  operations  center  (TOC)  workstation 
software,  was  developed  in  modular  fashion. 

Use  of  modular  software  allowed  the  simulation  software  to 
be  rapidly  reconfigured  to  meet  research  needs  by  using  keyboard 
software  switches  (documented  in  this  product) .  As  each 
successive  portion  of  the  CVCC  research  was  conducted  and  after 
action  questionnaires  and  interviews  of  the  soldier  participants 
were  completed,  changes  were  made  to  the  software  and  hardware. 
The  questionnaires  and  interviews  contained  specific  queries 
related  to  the  SMIs  presented  in  each  portion  of  the  research. 
These  conunents,  in  addition  to  SME  observations,  were  used  to 
refine  the  software  in  the  next  phase  of  the  evaluations, 

A  systematic  iterative  approach  to  software  development  was 
derived  and  served  to  provide  software  that  was  effective  and 
robust  in  relatively  short  periods  of  development.  The  approach 
is  outlined  as  follows: 
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•  Functional  descriptions  were  prepared  by  SME. 

•  Coordination  meetings  were  held  between  SMEs  and 
software  engineers. 

•  Story  boards  were  prepared  by  the  software  engineers  and 
were  reviewed  and  modified  by  SME  and  researchers. 

•  An  initial  listing  of  measures  of  effectiveness  and 
performance  were  made  known  to  the  software  engineers  at 
this  time  so  that  data  elements  could  be  inserted  in  the 
software . 

•  Interactive  interface  displays  and  controls  were 
prepared  using  rapidly  prototyped  software  and  were 
retained  at  the  MWTB  for  review  by  researchers  and  SMEs. 
Rapid  feedback  was  provided  to  the  softv/are  engineers. 

•  Software  integration  testing  was  conducted  by  the 
software  engineers  at  the  MWTB.  At  the  conclusion  of 
the  integration  testing,  the  software  was  demonstrated 
to  researchers  and  SMEs.  Feedback  was  provided  during 
round  table  discussion. 

•  Initial  operational  software  was  delivered  and 
installed.  Functional  testing  was  conducted  by  site 
staff  and  by  researchers.  The  functional  testing  was 
also  used  to  train  the  researchers  and  research 
assistants  on  the  capabilities  of  the  software. 

Feedback  about  bugs  and  required  modifications  were 
provided  to  the  engineers  daily. 

•  Bug  fixes  and  modifications  were  incorporated  and 
confirmed  by  researchers  and  SMEs. 

•  A  functional  test,  utilizing  soldier  crews,  was 
conducted  to  confirm  the  functionality,  the  training 
program,  and  data  collection  procedures. 

•  Final  fixes  to  software,  training,  and  data  collection 
procedures  were  made. 

•  Formative  evaluations  were  conducted. 

As  in  any  research  program,  not  all  software  fixes  were 
successful  and  many  lessons  were  learned  in  each  phase  of  the 
program.  This  document  presents  a  picture  of  the  software 
architecture  at  the  conclusion  of  the  CVCC  battalion-level 
formative  evaluation.  The  software  is  robust  and  functional,  but 
even  at  this  stage  there  remain  bugs  that  have  not  been  corrected 
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and  modifications  that  the  researchers  and  the  SMEs  would  like  to 
have  made. 


Charles  K.  Heiden,  P.E. 
Maj  Gen,  U.S.  Army  (Rtd) 
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COMBAT  VEHICLE  COMMAND  AND  CONTROL  SYSTEM  ARCHITECTURE  OVERVIEW 


THE  SIMULATED  WORLD  OF  THE  CVCC  MOUNTED  WARFARE 

TEST  BED  (MWTB) 


This  part  of  the  report  describes  what  is  simulated  in 
the  virtual  world  of  the  CVCC  MWTB,  how  it  is  simulated,  and 
how  the  pieces  of  the  simulation  work  together. 


What  Is  Simulated? 

This  section  describes  the  various  elements  of  the  real 
world  that  are  simulated  in  the  virtual  world  of  the  CVCC 
MWTB.  Figure  1  provides  a  conceptual  view  of  these  elements. 


Terrain  and  Environmental  Effects 

The  virtual  world  of  the  CVCC  MWTB  covers  a  50x75- 
kilometer  region  around  Fort  Knox,  Kentucky.  The  virtual 
world  includes  the  terrain  contours,  vegetation  (including 
tree  lines  and  tree  canopies) ,  rivers,  and  man-made  objects 
such  as  roads,  buildings,  and  bridges. 

In  addition,  a  limited  number  of  environmental  effects, 
such  as  the  time  of  day  and  the  effects  of  haze  on 
visibility,  are  included.  These  were  not  utilized  during  the 
CVCC  formative  evaluations , 


Combat  Vehicles  and  Combat  Forces 

The  world  of  the  CVCC  MWTB  focuses  on  force-on- force 
warfare  at  the  battalion  level  and  below.  The  friendly 
forces  consist  of  an  armored  tank  battalion  of  the  U.S.  Army 
with  normal  artillery  support.  The  opposing  forces  consist 
of  armored  regiments  organized  according  to  the  doctrine  of 
the  former  Soviet  Red  Army. 

The  following  types  of  equipment  are  represented: 
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Figure  1,  Real  world  elements  simulated  in  the  virtual  world. 


•  CVCC-equipped  tank 

•  M3  Bradley  Fighting  Vehicles 

•  Howitzers 

•  Mortars 

•  T72  tanks 

•  BMPs 

The  CVCC-equipped  tank  is  an  Ml  tank  enhanced  with 
various  weapons  and  command  and  control  systems,  including 
the  Commander's  Independent  Thermal  Viewer  (CITV)  and  the 
Autoloader  System,  the  SINgle  Channel  Ground/Air  Radio  System 
(SINCGARS) ,  and  the  Command  and  Control  Display  (CCD) . 

The  CITV  is  mounted  on  the  turret  and  is  capable  of 
slewing  independently  of  it  through  270  degrees  of  rotation, 
providing  the  commander  with  an  infrared  view  of  the 
battlefield.  In  addition,  an  Identification  Friend  or  Foe 
(IFF)  System  has  been  built  into  the  CITV,  allowing  the 
Commander  to  view  the  IFF  symbol  for  a  potential  target .  The 
CCD  is  located  in  the  commander's  station  in  the  tank. 

The  Autoloader  enhancement  to  the  CVCC  tank  removes  the 
onus  of  manually  loading  the  ammunition  for  the  tank.  Thus, 
the  role  of  the  loader  need  not  be  filled  in  a  tank  ecjuipped 
with  an  autoloader,  so  that  the  tank  could  be  fully  manned 
with  only  3  crew  members.  Mechanical  prototypes  of 
autoloaders  have  been  built  for  the  Ml,  though  none  have  ever 
been  fielded.  The  CVCC  tank  incorporates  this  capability. 

The  SINCGARS  radio  is  a  new  family  of  VHF-FM  combat 
network  radios  designed  to  provide  the  primary  means  of 
command  and  control  for  combat  units,  combat  support  units, 
and  combat  service  support  units  in  the  Army.  SINCGARS 
radios  improve  on  the  previous  generation  of  tactical  radios 
by  providing  more  channels,  better  communication  security, 
better  Electronic  Counter-Counter  Measure  (ECCM)  capability, 
and  greater  reliability.  The  SINCGARS  family  includes  a 
series  of  modular  components  that  can  be  combined  in 
different  configurations  to  produce  a  variety  of  "manpack, " 
table-top,  and  vehicle-borne  radios.  In  the  CVCC  MWTB,  a 
SINCGARS  simulation  provides  the  communications  link  for 
tank-to-tank,  tank-to-TOC,  and  TOC-to-tank  communications. 

The  CCD  is  a  prototype  of  a  vehicle-based  Command  and 
Control  system  that  allows  the  tank  commander  to  send,  receive, 
and  manipulate  various  types  of  command  and  control  data 
including; 
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•  vehicle  location  information  (POSNAV) 

•  vehicle  status  information,  such  as  fuel  and 
ammunition  status 

•  Anriy  reports,  such  as  Spot  reports.  Contact  reports, 
cuid  Call-For-Fire  (CFF)  reports 

•  graphical  overlays  such  as  OpOrds  and  Fire  Support 
overlays 

•  Driver's  Steer-to 

BftttaUgn  Tacticftl-Operatigns...  Center 

fBnTOC) 

In  addition  to  the  CVCC-teuik  based  CCD,  the  world  of  the 
CVCC  MWTB  supports  command  and  control  functions  through  the 
simulation  of  the  Battalion  Tactical  Operations  Center  using 
the  computer-based  BnTOC  workstations.  Together  with  the 
CCD,  the  introduction  of  the  BnTOC  workstations  into  the  CVCC 
MWTB  represents  a  bottom-up  attempt  at  integrating  computer- 
based  command  and  control  systems  into  the  battlefield.  The 
BnTOC  workstations  provide  the  connecting  link  between  the 
battalion  staff  and  the  CVCC-tank  based  CCDs.  They  were 
built  in  response  to  the  need  to  support  battalion-level  CVCC 
experiments  and  to  allow  the  CCD-equipped  tank  simulators  to 
communicate  digitally  with  the  BnTOC. 

Currently,  the  CVCC  simulation  includes  five  different 
workstations  (not  all  required  functions  were  implemented  in 
these  workstations  due  to  time  and  funding  restraints) .  The 
workstations  are; 

•  Planning  workstation 

•  Operations  workstation 

•  Intelligence  workstation 

•  Fire  Support  workstation 

•  Combat  Service  Support  (CSS)  Workstation 

An  additional  workstation  is  available  to  drive  a  6x4 
foot  electronic  Situation  Display.  Future  work  in  the  MWTB 
could  add  a  workstation  for  the  personnel  function. 

BnTOC  workstations  allow  the  TOC  officers  to  digitally 
send  and  receive  the  same  command  and  control  information  as 
the  tank  commanders  (with  the  exception  of  vehicle  status 
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information  which  the  BnTOC  workstations  can  only  receive) . 
The  BnTOC  workstations  give  the  TOC  officers  computer-based 
assisteince  in  planning  and  conducting  a  battle.  For 
battlefield  and  mission  planning,  the  BnTOC  workstation 
provides  a  tactical  map  and  the  ability  to  edit  a  rich 
variety  of  graphical  overlays,  including  operations, 
intelligence,  and  concept-of -operations  overlays  (which 
provide  information  about  the  movements  of  units  through 
various  phases  of  an  operation) .  During  the  actual  battle, 
the  BnTOC  provides  an  integrated  environment  in  which  reports 
from  the  battalion's  combat  vehicles  can  be  quickly  and 
easily  integrated  into  the  evolving  picture  of  the 
battlefield  situation  as  summarized  in  the  form  of  graphical 
overlays,  and  quickly  shared  with  the  appropriate  parties, 
including  the  company  coitvmanders  and  other  battalion  TOC 
officers.  The  software  is  configured  so  that  each  BnTOC 
workstation  has  access  to  files  belonging  to  the  other  BnTOC 
workstations,  in  effect  creating  a  shared  database  of  command 
and  control  information  and  allowing  rapid  integration  of 
operations,  intelligence  and  logistical  information. 

CCD  and  the  BnTOC  workstations  both  use  SINCGARS  as 
their  transmission  medium.  Figure  2  shows  how  the  SINCGARS, 
CCD,  and  BnTOC  systems  work  together  to  form  a  hierarchical 
Battalion  Command  network  in  which  an  individual  tank  can 
transmit  voice  and  data  up  to  the  battalion  headquarters  and 
potentially  beyond  to  brigade  and  division  level.  All  tanks 
in  a  particular  command  network  can  send  and  receive  voice 
and  data  to  all  other  tanks  on  that  network.  In  addition, 
the  commander  of  a  particular  unit  can  communicate 
information  up  the  chain  of  command  to  the  next  higher 
command  network.  In  this  way,  information  flows  up  the  chain 
of  command  from  the  individual  tanks  belonging  to  a  platoon- 
level  command  network,  to  the  corresponding  company  and 
battalion  command  networks.  In  like  manner,  intelligence 
information  and  command  and  control  data  flow  down  through 
successive  echelons. 
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How  Is  It  Simulated? 


This  section  explains  how  the  elements  of  the  real  world 
described  above  are  simulated  (see  Figure  3) .  It  describes 
the  following  major  software  and  hardware  systems  of  the  CVCC 
MWTB  and  what  they  simulate.  It  also  describes  how  these 
systems  interact  and  communicate  with  one  another: 

«  Terrain  databases 

•  CVCC  manned  and  unmanned  vehicle  simulators 

•  BnTOC  Workstations 

•  Data  cinalysis  systems 

Figure  4  provides  2Ui  overview  of  the  simulation  network. 


Terrain  Ba^tabagas 

Each  system  participating  in  the  simulated  battlefield 
of  the  CVCC  MWTB  uses  a  copy  of  a  common  terrain  database 
that  describes  a  5 0x7 5 -kilometer  area  around  Fort  Knox, 
Kentucky,  This  terrain  database  is  derived  from  Level  I 
Defense  Mapping  Agency  Data  consisting  of  soil  type  and 
elevation  data  sait5>led  at  90-meter  (3  arc  second)  intervals. 
This  DMA  data  is  enhanced  with  microterrain  (hills)  and 
feature  data  (buildings,  railroads,  etc.)  and  converted  into 
two  different  formats  for  use  by  systems  in  the  CVCC  MWTB. 

One  format  primarily  uses  polygons  in  three  dimensions  to 
describe  all  the  objects  in  the  terrain.  This  format  is  well 
suited  for  use  by  the  Computer  Image  Generator  (CIG)  which 
produces  the  "out-the~window"  views  for  the  manned  vehicle 
simulators.  The  second  format  is  a  simplified  version  of  tne 
first  in  which  the  three-dimensional  information  is  collapsed 
into  two  dimensions.  This  format  is  well  suited  for  systems 
that  require  only  a  two-dimensional  view  (i.e,,  a  map)  of  the 
terrain.  In  either  format,  the  database  includes  terrain 
features  such  as  contours,  rivers,  and  vegetation,  as  well  as 
man-made  cultural  features  such  as  roads,  buildings,  and 
bridges.  For  a  more  detailed  description  of  the  process  of 
SIOOO  Terrain  Datcibase  Generation,  see  Appendix  B. 
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Figure  3.  How  real  world  elements  are  simulated  in  the  virtual  world. 
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Figure  4.  CVCC  MWTB  simulation  network. 


CVCC  Manned  and  Unmanned  Vehicle 

SimuIatQga 


simulating  friendly  forces  involves  both  manned  and 
unmanned  vehicle  simulators.  Simulating  opposing  forces 
involves  unmanned  vehicle  simulators  only. 

Manned  vehicle  simulators  allow  the  "live  play"  caused 
by  human  decision-making  and  hxunan  error  to  become  a  part  of 
the  simulation.  Manned  simulators  usually  include  the 
following  major  subsystems: 

•  an  enclosure  that  replicates  the  interior  of  the 
vehicle  being  simulated 

•  controls,  sensor  displays,  and  out-the-window  displays 
for  the  crew 

•  computer  image  generators  (CIGs)  for  out-the-window 
and  sensor  views 

•  a  visual  model  of  the  appearance  of  all  dynamic 
entities  in  the  exercise 

•  a  sound  system 

•  a  host  computer  called  the  SimHost,  which  runs  the 
software  model  of  the  vehicle  and  associated  weapons 
systems 

•  a  connection  to  the  simulation  network 

Unmanned  vehicles  in  the  CVCC  MWTB  are  primarily 
generated  using  the  Semi -Automated  Forces  (SAF)  system. 


Manned  -aj.roulatqrs ;  The ,  CVCC,  Tank 

In  the  CVCC  MWTB,  the  only  manned  vehicle  simulators 
used  are  CVCC-equipped  teinks.  The  CVCC  enhancements  include: 

•  the  Commander's  Independent  Thermal  Viewer  (CITV) 

•  the  Autoloader 

•  the  SINCGARS  radio 

•  the  CCD 

The  CITV  and  the  Autoloader  were  both  implemented  as 
extensions  to  the  core  Ml  meumed  vehicle  simulator  software. 
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As  with  out-the-window  views,  the  CIG  and  the  SimHost 
cooperate  to  produce  the  simulation;  the  SimHost  determines 
what  is  viewed,  and  the  CIG  generates  the  views.  The 
SINCGARS  and  CCD  capabilities  are  implemented  as  software 
systems  that  are  completely  separate  from  the  enhanced  Ml 
vehicle  simulator.  Details  on  how  these  simulations  are 
constructed  and  how  they  cooperate  to  form  the  complete  CVCC 
simulation  are  provided  in  the  section  describing  the  BnTOC 
Workstation.  For  CVCC  Tank  simulator  operator  instructions, 
see  Smith,  1991. 

CITV-gimulation- 

The  CITV  simulation  provides  a  two-axis  stabilized 
thermal  viewing  platform  independent  of  the  tank  gunner's 
view.  The  thermal  viewer  provides  both  low  and  high 
magnification  and  a  choice  of  either  white  hot  or  black  hot 
viewing  modes.  The  commander  may  access  a  number  of 
capabilities  of  the  CITV  simulation,  described  below,  from 
controls  located  around  the  CITV  display  and  on  the 
commander's  control  handle.  Figure  5  depicts  the  CITV 
display  and  its  relationship  to  the  CCD  display.  The 
following  capabilities  are  provided  with  the  CITV: 

•  Independent  Laser  Range  Finder  (LRF) :  Provides  the 
capability  to  lase  a  selected  spot  on  the  battlefield. 
When  the  commander  lases  a  location,  the  range  to  that 
destination  is  displayed  on  the  CITV.  This  capability 
is  often  used  to  lase  a  vehicle,  to  determine  its 
range.  The  lasing  function  is  also  used  as  the  basis 
for  other  CITV  functions. 

•  Manual  and  Automatic  Thermal  Scanning  of  the 

Battlefield:  Provides  an  independent  ability  for  the 

commander  to  observe  the  battlefield.  The  commander 
is  provided  the  ability  to  select  3  and  10  power 
magnification,  manual  control  of  battlefield 
surveillance  or  automatic  scanning  between  commander 
defined  right  and  left  limits  of  scan. 

•  Integrated  Reporting:  This  capability  provides 
integration  of  the  CITV  and  CCD.  If  the  CCD  is  in 
report  creation  mode  when  the  LRF  is  used  and  an 
active  location  field  is  present  in  the  report,  the 
CCD  uses  information  provided  by  the  CITV  to 
automatically  fill  in  that  field  with  the  lased 
location  in  standard  six-digit  UTM  map  coordinates. 

•  Identification  Friend  or  Foe  (IFF) ;  Simulates  the 
ability  of  an  automated  Identify  Friend  or  Foe  system 
by  depicting  an  IFF  symbol  in  the  upper  left  hand 
corner  of  the  CITV  display  whenever  a  possible  target 
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is  lased.  Probabilities  of  obtaining  an  accurate 
identification  are  range  based,  and  can  produce 
incorrect  results  at  long  ranges. 

•  Target  Designation:  Allows  the  commander  to  designate 
a  current  target  location  by  causing  the  turret  and 
cpan  to  automatically  slew  so  that  the  gunner's  sight 
is  on  the  target. 

•  Target  Stack  Capability:  Allows  the  commander  to 
establish  up  to  four  (4)  target  tracks  in  a  stack. 

The  gunner  subsequently  selects  a  target  from  the 
stack  and  the  turret  and  gun  automatically  slew  in 
azimuth  so  that  the  gunner's  sight  is  laid  on  the 
predicted  azimuth  of  the  target .  The  Target  Stack 
Capability  was  not  used  during  the  battalion  formative 
evaluations . 


Figure  5.  CVCC  displays. 


Autoloader  simulation. 

The  Autoloader  simulation  provides  an  autoloading 
capability  for  the  CVCC  tank  simulator  main  gun.  This 
capability  performs  the  role  of  the  loader,  by  automatically 
loading  the  selected  ammunition  for  the  tank.  Since  this 
function  is  performed  automatically,  no  separate  controls  or 
capabilities  need  to  be  accessed  by  the  crew  of  the  tank. 
Further,  since  the  role  of  the  loader  is  automatically 
filled,  a  CVCC  tank  simulator  can  be  fully  manned  with  only 
three  crew  members. 
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The  Autoloader  functions  as  follows: 

•  From  trigger  pull,  the  gunner  has  a  3  second  pause  to 
change  ammo  types  if  he  so  desires;  otherwise  the 
autoloader  will  load  the  same  type  round. 

•  Total  cycle  time  from  trigger  pull  until  the  "loaded" 
light  comes  on  is  8  seconds. 

<»  If  the  gunner  changes  the  ammo  type  by  changing  his 
selector  switch  after  a  new  round  is  loaded  the 
autoloader  will  unload  and  reload  with  the  new  type  of 
ammo  -  time  is  9  seconds. 

The  times  to  reload  and  reposition  main  gun  rounds  from 
hull  stowage  or  from  another  tank  were  not  changed  from  the 
baseline  Ml  simulator. 


SINCGARS  simulation. 

Two  types  of  SINCGARS  radios  are  simulated  in  the  CVCC 
MWTB.  The  table- top  model  is  used  in  the  battalion  TOC  for 
TOC-to-tank  communications.  The  vehicle-based  model  is  part 
of  the  overall  CVCC  tank  simulation  and  is  used  for  tank-to- 
tank  and  tank~to-TOC  communications.  A  single  software 
program  is  used  for  both  models,  and  the  capabilities  are 
virtually  identical. 

The  SINCGARS  radio  simulator  has  a  front  panel  with 
controls  that  look  like  and  selectively  function  in  the  same 
way  as  those  in  the  real  radios.  It  has  Input/Output  (I/O) 
hardware  that  includes  Analog  to  Digital  (A/D)  and  Digital  to 
Analog  (D/A)  converters,  and  a  processor  to  digitize  and 
compress  speech,  making  the  speech  ready  for  efficient 
tremsmission  on  the  local-area  network  (LAN) .  The  radio 
simulation  includes  a  software-based  Radio  Interface  Unit 
(RIU) ,  which  negotiates  between  voice  and  data  transmissions. 
It  has  the  ability  to  simulate  the  frequency-hopping 
capabilities  of  the  real  SINCGARS  radio,  and  it  includes  a 
propagation  model  that  accounts  for  effects  such  as 
attenuation  of  signal  strength,  jamming,  and  terrain 
interference. 


CCD. simulation. 

The  CCD  simulation  uses  a  13-inch,  full-color,  high- 
resolution  cathode  ray  tube  (CRT)  monitor  as  the  basis  for 
the  display  in  the  tank  commander's  station.  The  simulation 
uses  a  graphical  user  interface  (GUI)  based  on  Open  Software 
Foundation's  (OSF)  Motif  to  implement  all  of  the  controls  in 
software.  The  input  devices  include  a  touch  screen  mounted 
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ovex"  the  display  and  a  thumb  controller  mounted  in  the 
commander's  control  handle.  In  addition,  there  is  a 
connection  to  the  simulation  network  and  an  interface  to  a 
"steer- to"  display  in  the  driver's  compartment . 

The  software  includes  a  map  module,  which  implements  the 
tactical  map  to  display  terrain  features  similar  to  those  on 
a  topographical  map  and  to  send,  receive,  and  display 
graphical  overlays.  A  navigation  module  provides  the 
ability  to  edit,  send,  receive,  and  display  routes.  The 
routes  consist  of  a  series  of  waypoints  that  appear  on  the 
tactical  map  when  the  route  is  displayed.  The  navigation 
module  also  sends  waypoint  information  to  a  steer-to  display 
mounted  next  to  the  steering  T-bar  in  the  driver's 
compartment.  A  report  module  provides  the  ability  to  edit, 
send,  receive,  and  display  formatted  Army  reports  (e.g., 

Spot,  Contact,  CFF,  Intel).  When  a  report  is  displayed, 
location  information  contained  in  it  is  displayed  in  the  form 
of  icons  on  the  tactical  map.  These  icons  can  th-n  be 
"posted"  to  the  tactical  map,  causing  them  to  remain  visible 
until  they  are  e.xplicitly  removed.  An  operational 
effectiveness  module  combines  the  vehicle  status  information 
(ammunition,  equipment,  fuel,  and  personnel)  into  graphical 
reports  that  summarize  the  operational  effectiveness  of  the 
vehicle  and  the  unit  to  which  the  CCD  belongs.  A  fire 
support  module  helps  the  user  to  construct  Call-For-Fire 
(CFF)  reports  based  on  UTM  coordinates  or  Target  Reference 
Points  (TPRs) .  Finally,  a  communications  module  provides  the 
capability  for  communications  either  directly  on  the  network 
or  via  a  SINCGARS  radio  simulation  for  the  full  array  of 
command  and  control  information,  including  vehicle  location, 
graphical  overlays,  routes,  reports,  and  vehicle  status. 


S.gnu.-Autamailfid... gorges  ( SAF.) 

Unmanned  vehicles  in  the  CVCC  MWTB  are  primarily 
generated  using  the  Semi -Automated  Forces  (SAF)  system.  One 
SAF  operator  can  control  about  60  SAF  vehicles.  To  human 
participants,  SAF  vehicles  are  usually  indistinguishable  from 
manned  simulator  vehicles  because  they  send  the  same  data 
packets  over  the  simulation  network  as  manned  simulators. 

SAF  vehicles  can  do  many  things  on  their  own.  The  SAF 
operator  needs  to  direct  the  SAF  vehicles  only  at  a  high 
level,  such  as  moving  them  from  one  location  to  another  or 
instructing  them  to  attack  the  enemy.  The  SAF  vehicles  fill 
in  many  of  the  details,  including  establishing  correct 
foirmations,  plotting  and  following  routes,  and  engaging  or 
fleeing  from  the  enemy. 
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The  SAF  simulators  include  the  following  major  subsystems: 


*  The  SAF  Station,  or  front  end,  provides  a  Graphical 
User  Interface  (GUI)  from  which  the  user  can  create 
and  control  groups  of  vehicles  organized  according  to 
the  doctrine  of  the  armed  forces  of  a  number  of 
different  countries,  including  the  United  States, 
Germany,  and  the  former  Soviet  Union. 

•  The  SAFSim,  or  back  end,  simulates  the  vehicles 
requested  by  the  user,  and  controls  their  actions  in 
response  to  the  high-level  commands  from  the  front 
end. 

SAF  can  be  used  to  simulate  a  wide  variety  of  vehicles, 
including  tanks,  fixed-wing  aircraft,  helicopters,  howitzers, 
mortars,  personnel  carriers,  and  supply  and  logistics 
vehicles.  In  the  CVCC  MWTB,  SAF  is  used  to  generate  the 
CVCC-equipped  tanks  and  scout  vehicles  (M3s)  for  the  friendly 
forces  as  well  as  all  the  opposing  forces.  The  friendly 
force  vehicles  (BLUFOR)  can  dispatch  digital  messages 
formatted  in  the  CVCC  format  into  the  C3  system. 

Using  SAF  makes  it  possible  to  run  larger  exercises 
without  having  to  man  every  vehicle.  Because  multiple 
unmanned  vehicles  can  act  as  a  unit  and  have  a  high  degree  of 
intelligence  and  independence,  they  can  be  combined  with 
manned  vehicle  simulators  in  various  ways.  The  configuration 
of  manned  and  unmanned  vehicle  simulators  being  used  for  the 
battalion-level  CVCC  experiments  is  a  good  example  of  this 
flexibility.  Manned  vehicle  simulators  are  used  for  the  key 
command  positions,  including  the  tanks  belonging  to  the 
Battalion  Commander,  S3,  and  A,  B,  and  C  Company  COs  and 
XOs.  All  remaining  tanks  in  the  Battalion  are  unmanned  SAF 
vehicles;  the  Scout  platoon  of  M3  vehicles,  platoons  1,  2, 
and  3  of  companies  A,  B,  and  C,  and  all  the  tanks  belonging 
to  Company  D.  In  the  companies  consisting  of  a  mixture  of 
manned  and  unmanned  vehicles,  the  platoons  of  unmanned 
vehicles  are  "tethered"  to  the  company  commander's  vehicle, 
allowing  them  to  move  and  act  more  as  a  single  cohesive  unit 
rather  than  3  separate  units.  In  the  company-level  CVCC 
experiments,  manned  vehicle  simulators  were  used  for  the 
company  headquarters  section,  and  for  one  of  the  platoons. 

The  other  platoons  were  simulated  by  SAF  vehicles.  Here,  too, 
the  SAF  platoons  were  "tethered"  to  the  company  commander's 
vehicle  in  order  to  force  them  to  act  more  as  a  cohesive 
unit . 


For  both  the  company-  and  battalion-level  experiments, 
the  friendly  SAF  tanks  were  enhanced  to  behave  more  like 
CVCC-equipped  tanks.  The  enhancements  included  alterations 
to  the  target  acquisition  tables  to  simulate  the  presence  of 
a  CITV  and  the  eibility  to  send  vehicle  location  (POSNAV,  or 
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position  NAVigation)  information,  vehicle  status  information, 
and  army  reports,  thus  simulating  the  output  of  a  CCD.  All 
these  enhancements  helped  to  make  the  SAP  tanks 
indistinguishable  from  manned  CVCC-equipped  tanks  in  the 
simulated  world  of  the  CVCC  MWTB.  To  create  a  consistent 
environment,  the  CVCC  capabilities  as  outlined  above  were 
provided  for  the  CVCC  M3  vehicles  in  the  Scout  platoon  as 
well . 


The  Management.  Command,  and.  Control  iMCC)  System 

A  second  system  used  in  the  CVCC  MWTB  to  generate 
unmanned  vehicles  is  the  Management,  Command,  and  Control 
(MCC)  system.  The  MCC  is  a  set  of  consoles  that  allow 
exercise  control  and  provide  logistics  and  combat  support. 

The  MCC  stations  include  a  master  console  for  exercise 
control  called  the  simulation  control  console  (SCO  and  five 
other  consoles  that  provide  GUIs  for  repair  and  recovery, 
resupply  (fuel  and  ammunition)  called  the  administration  and 
logistics  console  (ALOC) ,  combat  engineering  support  (CES) , 
fire  support  element  (FSE) ,  and  close  air  support  (CAS)  roles 
during  an  exercise.  In  the  CVCC  formative  evaluation  not  all 
of  these  capabilities  were  necessary  or  utilized.  Each  of 
these  consoles  communicates  with  the  MCC  backend  which,  like 
the  SAP  Sim,  is  responsible  for  controlling  the  unmanned 
vehicles.  In  the  CVCC  MWTB,  the  MCC  vehicles  have  fewer 
capabilities  and  less  built-in  intelligence  than  SAP 
vehicles . 

In  the  CVCC  MWTB,  the  MCC  is  used  to  generate  the 
howitzer  and  mortar  vehicles  for  the  simulated  world.  These 
vehicles  can  execute  various  types  of  fire  support  functions, 
including  pre-planned  fires  and  calls-for-fire.  One 
limitation  of  these  MCC  vehicles  is  that  they  are  not  visible 
when  traversing  the  terrain.  They  disappear  from  the 
simulated  world  for  the  time  that  they  require  to  travel  from 
one  place  to  another,  and  then  reappear  at  the  destination. 

In  effect,  MCC  vehicles  are  teleported,  though  the 
teleportation  takes  the  appropriate  amount  of  time. 


BaTQC 

The  BnTOC  workstation  has  two  full-color,  19-inch 
monitors  connected  to  an  engineering  workstation.  The 
simulation  uses  a  GUI  based  on  OSF  Motif  to  implement  all  of 
the  user  controls. 

The  BnTOC  workstation  shares  all  of  the  software 
capabilities  of  the  CCD  simulation  except  the  navigation 
module.  It  also  has  a  number  of  additional  capabilities, 
which  are  enumerated  below. 
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The  map  module  in  the  BnTOC  workstation  provides  the 
ability  to  edit  graphical  overlays  in  addition  to  sending, 
receiving,  and  displaying  them.  The  BnTOC  workstation  also 
handles  a  special  type  of  overlay,  a  concept-of -operations 
(COO)  overlay,  not  available  in  CCD.  The  COO  Submodule 
enables  the  user  to  edit  and  display  concept-of-operations 
overlays  on  the  tactical  map.  Concept--of-operations  overlays 
consist  strictly  of  unit  icons  belonging  to  an  organic  task 
organization  hierarchy  such  as  an  armor  battalion.  The  task 
organization  hierarchy  can  be  de-aggregated  to  the  desired 
level,  and  each  of  the  resulting  unit  icons  in  the  task 
organization  can  be  placed  in  a  series  of  battlefield 
locations  corresponding  to  the  unit's  battle  positions  for 
the  various  phases  of  the  operation.  By  stepping  the  unit 
icons  through  their  battle  positions,  the  user  can  reveal  the 
operation  phase  by  phase. 

The  BnTOC  workstation  has  an  enhanced  operational 
effectiveness  capability,  including  different  types  of 
reports  and  a  greater  ability  to  determine  the  status  of 
specific  elements  of  the  battalion.  In  CCD,  the  tank 
commander  has  access  to  reports  suiranarizing  the  status  of  his 
own  tank  or  his  own  unit  with  regard  to  fuel,  amn\unition,  or 
equipment.  These  reports  are  bar  charts  that  display  the 
amount  available  and  the  amount  consumed.  In  the  BnTOC 
workstation,  the  TOC  officer  can  display  these  reports  for 
any  unit  within  the  battalion  and  for  the  battalion  as  a 
whole.  In  addition,  the  TOC  officer  can  display  summary 
reports  that  show  the  fuel,  ammunition,  equipment,  and 
personnel  status  simultaneously  in  the  form  of  a  standard 
Army  GARB  pie  chart. 

The  BnTOC  workstation  includes  a  format  module,  a  job- 
aid  which  assists  the  user  in  creating  a  variety  of  Ainny 
reports  and  documents  (e.g.;  Est/Sit,  OpnOrd,  INTSUM,  etc.). 

The  BnTOC  network  as  configured  in  the  CVCC  MWTB 
includes  a  total  of  six  BnTOC  workstations.  Three  are  used 
to  support  the  battalion  staff  officers  including  an  S2 
workstation  for  the  intelligence  officer,  an  S3  workstation 
for  the  operations  officer,  and  a  Planning  workstation  for 
the  battalion  commander  and  executive  officer.  A  fourth 
workstation  is  used  by  the  fire  support  coordinators  assigned 
to  the  battalion  TOC  from  the  divisional  artillery  battalion. 
A  fifth  workstation  is  used  to  support  the  logistic  function 
and  to  assist  in  exercise  control,  and  a  sixth  workstation  is 
used  to  drive  the  electronic  situation  display  (SitDisp) . 
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After-Actiga,. Review.  Cata,,, Analysis,,  and 

CVCC  utilities 

Several  systems  that  are  part  of  the  CVCC  MWTB  do  not 
play  an  active  role  in  creating  the  simulated  world.  Rather, 
these  systems  support  the  simulation  and  the  use  of  the  CVCC 
MWTB  as  an  experimentation  testbed.  These  systems  can  be 
divided  into  three  categories : 

•  After-action  review 

•  Data  analysis 

•  CVCC  utilities 


A£tgx-Agi;i.gn  Review 

Three  separate  systems  are  combined  to  provide  the 
after-action  review  (AAR)  system  in  the  CVCC  MWTB.  They  are 
the  stealth  vehicle,  the  data  logger,  and  the  plan  view 
display.  The  AAR  system  is  used  to  determine  what  part  of  a 
recorded  exercise  should  be  played  back.  It  provides 
capabilities  similar  to  that  of  a  tape  or  video  recorder, 
including  play,  rewind,  fast  forward,  and  search  modes. 

Using  the  stealth  vehicle,  data  logger,  and  PVD,  the  operatoi* 
can  see  a  two-dimensional  and  a  three-dimensional  view  of  any 
portion  of  the  exercise  from  any  position  in  the  terrain 
database . 

The  stealth  vehicle,  as  its  name  implies,  provides  a 
window  onto  the  battlefield  without  being  seen  (Katz,  1990) . 
Because  the  stealth  vehicle  emits  no  data  packets  (see  the 
section  on  the  simulation  protocol) ,  it  is  invisible  to  all 
participants  and  cannot  affect  the  exercise.  The  stealth 
vehicle  is  very  useful  for  AAR  because  of  its  ability  to  move 
quickly  to  any  location  on  the  battlefield  and  view  the 
battlefield  from  any  direction.  A  stealth  vehicle  includes: 

•  a  control  to  manipulate  the  stealth  view  in  six 
degrees  of  freedom 

•  a  computer  image  generator  (CIG)  for  out-the-window 
views 

•  a  sound  system  (optional) 

•  a  simple  first-order  model  for  the  vehicle  dynamics 

•  a  visual  model  of  the  appearance  of  all  other  dyneimic 
entities  in  the  exercise 
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•  a  connection  to  the  network 


*  a  terrain  database 

The  data  logger  supports  the  AAR  functions  by  providing 
recording  and  playback  functions  much  like  those  of  a  tape 
recorder.  In  recording  mode,  the  data  logger  uses  its 
connection  to  the  network  to  save  all  the  packets  sent  over 
the  network  during  an  exercise,  along  with  a  timestamp 
indicating  when  they  arrived.  In  playback  mode,  the  data 
logger  writes  all  the  packets  back  out  to  the  network,  using 
the  timestamps  to  ensure  the  correct  time  sequencing. 

The  plan  view  display  (PVD)  console  displays  a  two- 
dimensional  tactical  map  showing  the  terrain  and  icons  for 
all  vehicles  participating  in  the  exercise.  The  PVD  also 
provides  interfaces  for  controlling  the  stealth  vehicle  and 
the  data  logger.  The  PVD  can  be  used  to  "teleport"  the 
stealth  vehicle  to  a  specified  location  or  to  attach  it  to  a 
specified  vehicle,  causing  it  to  follow  wherever  that  vehicle 
goes.  The  PVD  can  also  be  used  to  direct  the  data  logger  to 
play  back  an  exercise  -  in  real  time  or  faster  than  real  time 
—  or  to  skip  to  a  specific  location  in  time  (rewind,  fast 
forward,  search) . 


Data  Analysis 

The  data  analysis  system  provides  the  ability  to  analyze 
the  statistical  data  recorded  by  the  data  logger.  These  data 
include  packets  of  information  sent  to  the  network  as  a 
result  of  noxTxial  interactions  among  simulation  programs 
during  an  exercise.  These  data  may  also  include  other  types 
of  information  sent  over  the  network  as  a  result  of  explicit 
"instrumentation"  packets  of  information.  Much  of  the  data 
collected  in  support  of  the  CVCC  software  was  the  result  of 
this  explicit  instrumentation. 

The  following  statistical  measures  are  available  without 
any  special  instrumentation: 

•  number  of  rounds  fired  by  each  combat  vehicle 

•  number  of  hits  scored  by  each  combat  vehicle 

•  average  distance  between  the  impact  point  of  a  round 
and  the  nearest  vehicle 

•  percentage  of  combat  vehicles  engaged  in  combat 

•  losses  of  combat  vehicles  on  each  side 
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Additional  information  packets  have  been  developed  and 
allow  recording  information  related  to  specific  measures  of 
effectiveness.  See  the  section  on  Instrumentation 
subprotocol  and  Loral  Advanced  Distributed  Simulation,  1991d, 
for  more  information. 


CVCC  UtiUtiea 

In  an  experiment,  the  ability  to  control  conditions  and 
reduce  the  number  of  variables  is  central  to  obtaining  useful 
data.  The  CVCC  utilities  aid  the  experimenters  in  setting  up 
the  initial  conditions  of  a  scenario  and  controlling  the 
exercise.  The  CVCC  utilities  include; 

•  Send  utility 

•  Listen  utility 

•  Checkpoint  utility 

The  Send  utility  can  be  used  to  batch- load  CVCC  reports 
into  all  CCD  and  BnTOC  workstations  participating  in  an 
exercise.  It  provides  an  easy  method  for  creating  a  well- 
defined  message  context  for  the  initial  conditions  of  an 
experiment.  Alternatively,  the  Send  utility  can  be  used  to 
send  CVCC  reports  in  real  time.  In  this  mode,  the  Send 
utility  can  act  as  a  stand-in  for  manned  and  unmemned 
vehicles  when  the  emphasis  is  strictly  focused  on  training 
soldiers  to  draw  correct  conclusions  about  the  current 
battlefield  situation  from  the  flow  of  Army  reports .  The  Send 
utility  is  also  used  to  represent  information  and  reports 
received  from  higher  or  adjacent  units. 

The  Listen  utility  is  useful  for  checking  what  command 
and  control  information  is  being  sent  over  the  network.  The 
Listen  utility  simply  reads  all  the  packets  on  the  network 
emd  prints  the  contents  of  any  packets  that  contain  command 
2ind  control  information  (see  the  description  of  the  CVCC 
protocol) . 

The  Checkpoint  utility  gives  the  CVCC  MWTB  a  limited 
capability  for  exercise  control;  it  defines  operations  that 
all  participating  systems  can  perform.  The  operations 
include  creating  a  checkpoint,  deleting  a  checkpoint,  and 
loading  a  checkpoint.  A  checkpoint  contains  information  on 
the  current  state  of  the  system.  It  is  useful  for  saving  the 
initial  conditions  of  an  experiment  so  they  can  be  easily 
recalled.  Checkpoints  are  also  useful  for  saving  the  interim 
conditions  when  the  evaluation  must  be  stopped  for  any  reason 
and  subsequently  resumed.  Currently,  the  BnTOC  workstations, 
CCD,  and  the  CVCC  simulators  participate  in  the  automatic 
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checkpoint  utility.  While  the  SAF  can  be  checkpointed  by 
hand,  it  is  not  part  of  the  automatic  checkpoint  utility. 


How  do  the  Pieces  Work  Together? 

The  software  and  hardware  systems  described  in  the  last 
section  are  able  to  participate  in  the  overall  simulated 
world  independently  of  the  number  and  variety  of  other 
systems  involved.  However,  these  systems  require  a  large 
amount  of  information  about  other  entities  in  the  simulated 
world  and  a  high  degree  of  cooperation  and  interaction  with 
other  entities  in  order  to  work  properly.  These  needs  are 
provided  through  the  use  of  networks  and  protocols . 

The  network  is  the  physical  medium  connecting  the 
various  systems  participating  in  the  distributed  interactive 
simulation.  Local-area  and  long-haul  networks  use  a  number 
of  different  physical  media,  including  Ethernet™,  dedicated 
telephone  lines,  and  satellite  links,  and  are  joined  to  form 
a  single  logical  network. 

Each  entity  participating  in  the  simulated  world  sends 
packets  of  information  onto  the  simulation  network.  These 
packets  conform  to  stemdard  formats  that  constitute  what  is 
called  a  communications  protocol.  Communications  protocols 
codify  the  rules  and  regulations  controlling  the  interaction 
between  the  various  entities  in  the  simulated  battlefield. 

This  section  briefly  describes  the  family  of  protocols 
used  in  the  CVCC  MWTB  to  control  the  interactions  between 
various  entities  in  the  simulated  world.  These  protocols 
include  the  following; 

•  simulation  protocol 

•  data  collection  protocol 

•  radio  simulation  protocol 

•  CVCC  protocol 

The  following  sections  describe  the  purpose  of  each 
protocol  euid  the  sofcware  and  hardware  systems  that  use  it. 
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aiiflulation  Protacoi 


The  information  reported  in  the  simulation  protocol 
includes: 

•  simulator  initialization  conditions 

•  locations  and  appearances  of  vehicles 

•  events  related  to  weapons  fire  and  collisions 

•  exchange  of  fuel  or  axnmunition  among  vehicles 

•  vehicle  malfunctions  and  repairs 

The  simulation  protocol  is  used  primarily  by  vehicle 
simulators  to  introduce  simulated  elements  into  an  exercise, 
remove  them  from  an  exercise,  and  convey  information  about 
the  simulated  world  for  use  by  simulators  (LADS,  1991d) . 

Systems  in  the  CVCC  MWTB  which  participate  in  the 
simulation  protocol  include: 

•  Enhanced  Ml  tank  simulator  (with  CITV  and  Autoloader) 

•  MCC 

•  SAP 

•  CCD 

•  SINCGARS 

The  simulation  protocol  is  central  to  the  operation  of 
the  enhanced  Ml  tank  simulator,  the  MCC,  and  the  SAP.  The 
enhanced  Ml  tank  simulator,  the  MCC,  and  the  SAP  send 
simulation  protocol  packets  to  communicate  the  current  state 
of  their  vehicles  including  the  vehicle  location,  the  vehicle 
appearance  (if  the  vehicle  has  a  normal  appearance,  is 
burning,  is  generating  a  dust  cloud,  etc.)/  turret 
orientation,  and  fuel  and  ammunition  levels,  among  other 
information.  Similarly,  they  send  simulation  protocol 
packets  to  communicate  the  occurrence  of  discrete  events  such 
as  weapons  firing,  munitions  detonation,  and  collisions.  The 
MCC  uses  the  simulation  protocol  to  reconstitute,  repair,  and 
resupply  simulated  vehicles  for  which  this  is  possible.  The 
enhanced  Ml  tank  reads  simulation  protocol  packets  to  display 
the  simulated  world  correctly  to  their  operators  in  the  out- 
the~window  views .  The  SAP  reads  simulation  protocol  packets 
to  update  its  map  display. 
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CCD  and  SINCGARS  simulators  use  the  simulation  protocol 
in  order  to  integrate  properly  with  the  enhanced  Ml  tank 
simulator  with  which  they  are  associated.  Both  systems  read 
the  simulation  protocol  packets  to  obtain  status  and  location 
information  about  their  own  vehicles.  The  CCD  uses  this 
information  to  correctly  depict  the  vehicle  on  the  tactical 
map  display.  The  SINCGARS  radio  uses  this  information  about 
its  own  vehicle  together  with  information  about  other 
vehicles  that  have  radios  to  do  proper  propagation  modeling. . 


Data  Gollegtign  PrQtggntl 

The  data  collection  protocol  is  used  to  report,  via  the 
network,  information  about  the  simulated  worlds.  Whereas  the 
simulation  protocol  conveys  information  of  interest  to 
simulators,  the  data  collection  protocol  conveys  additional 
information  that  is  primarily  of  use  to: 

•  analysts  who  may  be  studying  an  exercise 

•  systems  that  must  monitor  the  state  of  an  exercise  to 
restart  it  or  resume  it  after  some  interruption 

In  the  CVCC  System  Architecture,  the  data  collection 
protocol  is  used  to  support  the  interoperability  between  the 
individual  systems  making  up  the  CVCC  tank.  The  enhanced  Ml 
tank  simulator  uses  the  data  collection  protocol  to 
communicate  information  about  how  the  Laser  Range  Finders 
(LRF)  are  being  used.  This  information  includes  which  LRF  is 
in  use  (Gunner  or  CITV)  and  whether  the  LRF  has  successfully 
located  a  target.  In  addition  to  being  useful  to  analysts, 
this  information  is  used  by  the  CCD  when  filling  out  reports. 
The  CCD  supports  entering  report  locations  (such  as  the 
location  of  enemy  vehicles  in  Spot  and  Contact  reports)  using 
the  CITV  Laser  Range  Finder. 


Radio.  Simulatign,  Pco.tocQl 

The  information  reported  in  the  radio  simulation 
protocol  includes: 

•  the  current  state  of  a  radio  transmitter,  including 
its  operating  state  and  what  vehicle  it  is  attached  to 

•  signals  containing  the  actual  voice  or  data 
transmissions 

The  radio  simulation  protocol  is  analogous  to  the 
(vehicle)  simulation  protocol  described  in  the  section 
describing  the  simulation  protocol.  It  can  be  thought  of  as 
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an  extension  to  the  simulation  protocol  to  support  radio 
simulations . 

In  the  CVCC  MWTB,  the  SINCGARS  radio  simulators  use  the 
radio  simulation  protocol  and  the  simulation  protocol  for 
SINCGARS-to-SINCGARS  transmissions.  The  SINCGARS  simulation 
uses  the  state  information  from  the  radio  simulation  protocol 
to  map  radios  to  vehicles.  It  uses  the  simulation  protocol 
to  determine  where  those  vehicles  (and  thus  the  radios)  are. 
With  this  information,  the  propagation  model  in  the  SINCGARS 
software  is  able  to  determine  what  radio  it  should  be 
listening  to,  and  reads  the  signal  information  from  that 
radio  only,  ignoring  signals  from  competing  radios  (Pope  et 
al.,  1990). 


.CLVC-C-EratOgfiLl 

The  CVCC  protocol  was  developed  specifically  to  support 
the  communication  and  interaction  requirements  of  the 
command,  control,  and  communications  systems  used  in  the  CVCC 
MWTB.  The  information  leported  in  the  CVCC  protocol 
includes : 

•  command  and  control  data 

•  information  about  current  CITV  orientation 

•  information  to  support  transmitting  data  via  the 
SINCGARS  radio 

•  instrumentation  information  for  data  collection 
purposes 

•  specialized  exercise  control  functions  required  by  the 
checkpoint  utility 

Each  class  of  infoirmation  serves  a  different  purpose  and 
is  used  by  different  software  components  of  the  CVCC  system. 
Each  of  these  classes,  its  users,  and  its  purpose  is 
discussed  in  the  paragraphs  that  follow. 

The  primary  use  of  the  CVCC  protocol  is  to  support  the 
commuiaication  of  command  and  control  information.  This 
information  includes  Army  reports,  graphical  overlays, 
vehicle  location  information  (POSNAV),  and  vehicle  status 
information,  which  includes  the  status  of  fuel,  ammunition, 
and  equipment.  The  BnTOC  workstation,  CCD,  and  SAP  use  the 
CVCC  protocol  to  send  and,  with  the  exception  of  SAP,  receive 
this  information  over  the  simulation  network.  When  no 
SINCGARS  radio  simulation  is  used,  the  CVCC  protocol  is  used 
to  transmit  command  and  control  information  directly  between 
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different  C3  simulation  software  components  (in  SAF,  the  CCD, 
and  BnTOC  workstations) . 

Part  of  the  CVCC  protocol  is  used  by  BnTOC  and  CCD  C3 
simulation  software  to  access  the  service  provided  by 
SINCGARS  radio  simulators.  When  the  SINCGARS  radio 
simulators  are  used,  C3  simulation  software  in  the  BnTOC 
workstation  and  the  CCD  transmit  their  command  and  control 
information  using  two  SINCGARS  simulators  as  intermediaries. 
The  sending  and  receiving  SINCGARS  simulators  simulate  the 
relevant  effects  of  radio  transmission  upon  the  receipt  of 
this  information. 

The  CVCC  protocol  supports  the  interoperability  of  the 
enhanced  Ml  tank  simulator  and  the  CCD.  The  enhanced  Ml  tank 
uses  the  CVCC  protocol  to  communicate  information  about  the 
current  orientation  of  its  CITV.  The  associated  CCD  uses 
this  information  to  correctly  depict  the  tank  on  its  tactical 
map. 


A  fourth  use  of  the  CVCC  protocol  is  to  provide  BnTOC- 
specific  and  CCD-specific  extensions  to  the  data  collection 
protocol  without  requiring  changes  to  the  data  collection 
protocol.  This  additional  information  is  recorded,  along 
with  standard  data  collection  information,  by  the  Data 
Logger.  To  provide  sufficient  data  to  support  the  CVCC 
experiments,  the  BnTOC  workstation  and  CCD  simulation  were 
made  to  report  a  wide  variety  of  information  about  their 
internal  status  and  how  they  are  being  used  by  the  operator.. 
The  CVCC  protocol  supports  the  communication  of  this 
"instrumentation"  information. 

Finally,  the  CVCC  protocol  is  used  to  coordinate  the 
operation  of  BnTOC  workstations,  CCDs  (and  attached 
vehicles),  and  SAF.  This  portion  of  the  protocol  is 
initiated  by  a  BnTOC  workstation  running  with  the 
"coordinator"  option.  With  this  option  active,  the  BnTOC 
workstation  also  functions  in  the  capacity  of  a  manager  (or 
coordinator)  for  CVCC  applications.  The  BnTOC  workstation, 
CCD,  and  SAF  applications  respond  to  this  portion  of  the 
protocol .  The  CVCC  tank  simulator  is  a  second-order 
participant,  responding  to  directions  from  its  associated 
CCD.  The  functions  supported  by  this  portion  of  the  protocol 
include  checkpointing  (creating,  deleting,  and  loading)  and 
shutting  down  CVCC  applications. 
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CVCC  HARDWARE  AND  SOFTWARE  ARCHITECTURE 


This  section  provides  a  more  detailed  description  of  the 
hardware  and  software  architecture  of  the  simulations 
developed  specifically  for  the  CVCC  program.  These 
simulations  include  the  enhanced  Ml  simulation  (CITV  and 
Autoloader) ,  SINCGARS  radio,  CCD,  and  the  BnTOC  workstation. 
CCD  and  the  BnTOC  workstation  are  presented  together  because 
they  share  many  of  the  same  functional  capabilities. 


Enhanced  Ml  Tank  Simulator 


The  Enhanced  Ml  Tank  Simulator  used  by  the  CVCC 
Simulation  is  implemented  using  a  SIMNET  Ml  tank  simulator  as 
a  base.  Historically,  the  SIMNET  Ml  simulator  used  the 
MASSCOMP™  5600  as  a  simulation  host  processor  and  a  BBN 
120T™  Computer  Image  Generator  (CIG) .  The  delivery  platform 
was  then  upgraded  to  the  dual-processor  GTlOl™,  which 
eliminated  the  need  for  a  separate  simulation  host  computer. 
The  GTlOl  was  the  standard  delivery  hardware  for  the  Ml 
simulator  at  the  start  of  the  CVCC  program.  The  Enhanced  Ml 
Tank  Simulator  is  based  on  the  GTlOl  version  of  the  Ml  tank 
simulator,  with  additional  enhancements  to  both  the  hardware 
and  software,  including  the  use  of  a  GTlll™,  as  will  be 
described  below. 

Functionally,  the  Enhanced  Ml  Tank  Simulator  differs 
from  the  baseline  Ml  tank  simulator  by  the  addition  of  a 
high-resolution  thermal  viewer  with  CITV  capabilities  and 
integration  of  the  Autoloader  functionality.  The  ammo 
capacity  of  the  simulators  was  also  modified.  The  Enhanced 
Ml  Tank  Simulator  has  a  full  load  of  40  main  gun  rounds  (in 
CVCC  formative  evaluations  this  consisted  of  27  rounds  of 
APDS  and  13  rounds  of  HEAT) . 

Hardware 

Figure  6  depicts  the  top  level  hardware  architecture  of 
the  Enhanced  Ml  Tank  Simulator,  The  GTlll  is  a  dual  processor 
computer  using  Motorola®  MVME147  boards .  The  main  processor 
hosts  the  Computer  Image  Generator  (CIG) .  The  second  MVME147 
board  hosts  the  Enhanced  Ml  Tank  Simulator  software. 
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Figure  6.  Hardware  architecture  for  Enhanced  Ml  Tank 
Simulator. 


The  GTlll  drives  the  network  interface  via  an  Ethernet™ 
driver  aboard  the  host  processor's  MVME147  card. 

Additionally,  the  GTlll  is  connected  to  the  hardware 
components  for  the  Status  Panel,  Sound  System,  Controls,  and 
Keyboard.  The  Status  Panel  monitors  the  simulator  hardware 
components  and  provides  an  indication  of  their  failure.  The 
hardware  interface  between  the  simulation  and  the  Status 
Panel  is  through  the  Burr  Brown®  MP830-72  TTL  I/O  card.  The 
Sound  System  is  used  to  provide  aural  cues  to  the  crew  of  the 
simulator  and  is  connected  via  an  RS-232  line.  The  Controls 
provide  the  crew  interface  to  the  vehicle  simulation  in  the 
form  of  toggles,  buttons,  meters,  etc,  and  are  connected  via 
an  RS-232  line  to  IDC  boards  which  provide  a  shared  memory 
interface.  The  Keyboard  is  used  during  development  and 
debugging  of  the  vehicle  simulator. 

The  notable  difference  between  the  GTlOl  and  GTlll  is 
that  the  GTlll  generates  a  high-resolution  view.  The 
Enhanced  Ml  Tank  Simulator  uses  this  view  to  drive  the  CITV 
display.  The  remaining  hardware  components  will  not  be 
described  in  greater  detail  in  this  document  since,  aside 
from  the  adoption  of  the  GTlll,  the  hardware  architecture  is 
described  in  other  documents  (Culviner  et  al,  1993;  Loral 
Advanced  Distributed  Simulation,  1991a;  Loral  Advanced 
Distributed  Simulation,  1991b;  and  Loral  Advanced  Distributed 
Simulation,  1991c) . 


The  top  level  software  architecture  of  the  Enhanced  Ml 
Tank  Simulator  is  the  same  as  the  standard  SIMNET  Ml  software 
architecture  and  depicted  in  Figure  7. 
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Figure  7.  Software  architecture  for  Enhanced  Ml  Tank 
Siir.ulator , 


The  Device  Interfaces  module  handles  communications 
between  the  simulation  processor  and  a  number  of  different 
devices,  including  the  CIG,  SIMNET  LAN,  sound  system,  status 
panel,  controls,  and  keyboard.  The  Vehicle  Simulation 
Functions  module  performs  the  actual  simulation  of  tank 
functions  and  its  processing  of  input  and  output.  These 
functions  include  modeling  hull  and  turret,  vehicle  dynamics, 
failures,  and  weapons  as  well  as  interaction  with  controls, 
lights,  meters,  and  the  simulation  network.  The  Vehicle 
Libraries  module  provides  generic  functions  useful  for  the 
simulation  of  any  kind  of  vehicle.  The  Simulation  Support 
Utilities  module  provides  generic  functions  useful  for  any 
software  module. 

Adding  the  CITV  functionality  of  the  Enhanced  Ml  Tank 
Simulator  primarily  affected  the  Vehicle  Simulation  Functions 
module,  where  the  additional  capabilities  of  the  CITV  are 
located,  but  required  supporting  modifications  within  all  top 
level  software  modules.  The  Autoloader  capability  required 
support  within  the  Vehicle  Simulation  Functions  module  and 
modification  to  the  Device  Interfaces  module.  The  Device 
Interfaces  module  was  modified  to  simulate  the  presence  of  a 
loader,  who  had  pressed  the  appropriate  buttons  at  the 
appropriate  times . 

Since  the  software  architecture  of  the  Enhanced  Ml  Tank 
Simulator  is  the  same  as  the  baseline  Ml  software 
architecture,  and  is  documented  in  chapter  2  of  the  Top-Level 
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Descriptions  for  SIMNET  Software,  it  will  not  be  described  in 
greater  detail  in  this  document  (see  Loral  Advanced 
Distributed  Simulation,  1990) . 


SINCGARS  Simulation 


^  NCGARS  ■  Hardware.  Ar.clii  tgg  tune 

The  vehicle  version  of  the  SINCGARS  simulator  in  the 
CVCC  MWTB  is  complicated  by  the  presence  of  an  internal 
intercom  system  and  multiple  radios.  This  makes  the  diagram 
and  description  of  the  hardware  architecture  more  complicated 
without  adding  any  fundcimental  understanding.  Therefore,  for 
the  sake  of  simplicity,  this  section  concentrates  on  the 
table-top  module  of  the  SINCGARS  simulator. 

Figure  8  shows  that  the  SINCGARS  simulator  hardware  is 
physically  divided  into  two  parts:  the  table-top  radio  box 
and  the  host  computer.  The  simulator  hardware  has  an 
interface  from  the  host  computer  to  the  real  hardware, 
including  real  SINCGARS  radios.  The  table-top  radio  box 
constitutes  the  user  interface  to  the  radio  simulator.  The 
host  computer  contains  the  radio  simulation  software. 
Currently,  the  host  computer  in  the  CVCC  MWTB  is  a  MASSCOMP 
6600. 


The  SINCGARS  radio  simulator  has  the  following  I/O 
subsystems; 

•  controls  I/O  subsystem 

•  speech  I/O  subsystem 

•  Ethernet  subsystem 

•  real-world  interface  subsystem 

The  controls  subsystem  has  a  front  panel  display  and 
hard  controls  that  implement  the  radio  settings  (channels, 
frequency  settings,  operation  modes,  push- to- talk  switch, 
etc.)  in  the  table-top  radio  box.  The  Front  Panel  Adapter 
(FPA)  and  the  Interaction  Device  Controller  (IDC)  detect  when 
the  user  manipulates  the  controls  and  send  signals  over  RS- 
232  lines  to  the  radio  simulation  software,  causing  the  radio 
simulation  to  change  its  behavior  (and  in  some  instances  the 
appearance  of  the  front  panel  controls)  appropriately. 
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Tabletop  Radio  Box  Host  Computer 


31 


The  speech  subsystem  includes  a  microphone  and  a  speaker 
in  the  table- top  radio  box.  These  are  the  analog  input  and 
output  devices  for  speech  transmissions.  The  analog  signals 
pass  through  eunplifiers  to  the  speech  I/O  board  in  the  host 
computer.  The  speech  I/O  (SIMVAD)  board  converts  the  voice 
signals  from  analog  to  digital  (and  from  digital  to  analog) 
fom  on  their  way  to  (and  from)  the  simulation  software  running 
on  the  host  processor.  To  accomplish  this,  the  voice  I/O  board 
has  A/D  (and  D/A)  convertei's  and  a  processor  to  compress 
(decompress)  the  digitized  speech  for  more  efficient 
transmission.  The  digitized  and  compressed  speech  is  then 
passed  to  the  radio  simulation  software  running  on  the  host 
processor  (CPU) .  Depending  on  the  current  state  of  the  radio 
as  defined  by  the  radio  simulation  software,  the  digitized 
speech  may  be  transmitted  to  the  other  SINCGARS  radio  simu¬ 
lations  via  the  Ethernet  subsystem  or  to  real  SINCGARS  radios 
via  the  real-world  interface  subsystem. 

The  Ethernet  subsystem  consists  simply  of' an  Ethernet 
board  connecting  the  host  computer  to  the  simulation  network 
Ethernet . 

The  real-world  interface  subsystem  includes  a  synchronous 
serial  port  in  the  host  computer,  connected  to  a  custom  board. 
The  custom  board  passes  the  voice  signal  to  the  real  SINCGARS 
radio,  where  it  can  be  transmitted  to  other  real  SINCGARS 
radios.  In  this  way,  soldiers  sitting  at  a  SINCGARS  radio 
simulator  in  the  CVCC  MWTB  can  communicate  directly  with 
soldiers  sitting  at  a  real  SINCGARS  radio  in  a  real  tank.  In 
addition,  the  custom  board  can  pass  data  transmissions  to  the 
Transportable  Computer  Unit  (TCU)  and  the  Adaptable 
Progreunmable  Interface  Unit  (APIU) ,  which  are  real-world 
devices  for  data  communications. 

SINCGARS  Software  Architecture 

In  a  CVCC-equipped  tank,  communications  are  provided  by 
three  separate  pieces  of  hardware.  Two  SINCGARS  radios  provide 
for  the  basic  voice  communications.  Data  communication  is 
mediated  by  an  intelligent  controller,  called  a  Radio  Interface 
Unit  (RIU) ,  that  is  connected  to  both  radios.  The  RIU  formats 
and  queues  data  for  transmission  on  radio  channels,  performs 
error  checking  and  correction  of  received  data,  and  implements 
schemes  for  addressing,  routing,  and  network  management.  The 
RIUs  of  the  various  vehicles  participating  in  a  single  combat 
radio  network  behave  as  packet-switching  nodes  to  provide, 
collectively,  a  dyneunic,  mobile  data  network  for  communication 
among  vehicles.  Some  RIUs  may  also  serve  as  bridges  or  gate¬ 
ways,  linking  two  or  more  combat  radio  networks  to  permit 
communication  among  vehicles  on  distinct  networks. 
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In  the  SINCGARS  radio  simulation,  a  single  process 
simulates  multiple  RIUs  and  the  radios  with  which  they  are 
associated.  The  total  number  of  RIUs  and  radios  that  can  be 
simulated  by  one  host  computer  is  limited  only  by  the 
computational  power  of  the  host.  The  effective  limit  of  the 
MASSCOMP  6600  used  in  the  CVCC  MWTB  is  four  RIUs  and  six 
SINCGARS  radios.  Thus,  one  host  computer  can  support  up  to 
three  CVCC  tank  simulations,  each  of  which  has  2  SINCGARS 
radios.  A  single  process  running  on  the  host  computer 
simulates  all  the  RIUs  and  all  the  radios  simultaneously. 

The  SINCGARS  radio  simulation  software  is  divided  into 
six  modules,  or  Computer  Software  Components  (CSCs) .  Three  of 
these  CSCs  —  the  network  I/O  interface,  the  front  panel  control 
interface,  and  the  speech  I/O  interface  —  maintain  interfaces 
to  three  of  the  I/O  hardware  subsystems  mentioned  in  the 
section  describing  the  SINCGARS  hardware  architecture  —  the 
controls  subsystem,  the  speech  subsystem,  and  the  Ethernet 
subsystem.  The  other  three  CSCs  —  the  radio  model,  the 
propagation  model,  and  the  RIU  —  implement  the  major  functional 
capabilities  of  the  SINCGARS  radio.  Figure  9  shows  a  block 
diagrcun  of  the  SINCGARS  radio  simulation  and  software 
architecture . 

The  network  interface  monitors  all  network  traffic.  It 
retrieves  radio  simulation  PDUs,  simulation  PDUs,  and  CVCC 
PDUs,  passing  them  on  to  other  models  via  the  communications 
module. 

The  front  panel  control  interface  samples  all  the  front 
panel  controls  relevant  to  the  communications  system,  and  then 
passes  their  state  to  the  radio  model .  Typical  parameters 
include  push- to- talk  button  status,  frequency  selection,  hopset 
selection,  and  radio/ intercom  select  switch  position.  In 
addition,  the  front  panel  interface  feeds  back  changes  to  the 
front  panel  controls  from  the  radio  model . 

The  speech  I/O  interface  contr-ols  the  flow  of  digitized 
speech  between  the  speech  subsystem  and  the  radio  model . 

The  radio  model  uses  the  radio  simulation  protocol  to 
effect  voice  communications  between  radio  simulations. 

The  propagation  model  adds  realism  to  radio  communications 
by  simulating  effects  such  as  terrain  obstruction,  distance 
attenuation,  weather,  and  soil  conditions. 

The  propagation  model  includes  a  simplified  terrain 
database  used  to  determine  terrain  interference. 
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The  Radio  Interface  Unit  (RIU)  simulation  provides  the  CCD  with  an 
interface  to  the  flINCGARS  radio  for  transmitting  and  receiving  data. 
It  performs  error  correction  on  data  corrupted  by  the  radio 
simulation.  Finally,  it  plays  the  role  of  a  multiplexer  for  sending 
both  voice  and  data  using  a  single  SINCGARS  radio.  It  does  this  by 
giving  priority  to  voice  transmissions  (see  National  Technical 
Information  Agency;  Ford  Aerospace  and  Communications  Corp.,  1986; 
Pope  et  al.,  1990;  and  U.S.  Army,  1986). 

SIMCGAES  Data  .Flow 

This  section  describes  the  path  that  voice  traverses 
through  a  simulator  when  it  is  sent  and  when  it  is  received. 

The  first  part  describes  the  path  of  voice  through  the 
SINCGARS  simulator.  It  includes  the  different  formats  that 
the  voice  data  takes  as  it  passes  through  the  various 
software  and  hardware  modules.  The  second  part  provides  an 
analogous  description  of  the  path  of  data  from  the  CCD 
simulation. 


Voice  Flow  Through  the  SINCGARS  Radio  Simulator 

Voice  begins  its  trip  through  the  SINCGARS  simulator 
when  a  radio  operator  keys  the  push-to-talk  switch  on  the 
table-top  radio  microphone.  This  sends  a  signal  through  the 
IDC  board  to  the  radio  simulation  software  on  the  host 
computer.  The  radio  simulation  software  starts  sampling  the 
appropriate  SIMVAD  board  for  the  speech  signals.  As  the 
operator  speaks  into  the  microphone  in  the  table- top  radio, 
an  analog  speech  signal  is  sent  through  the  amplifier  to  the 
SIMVAD  board,  where  it  is  digitized  and  compressed.  The 
digitized  and  compressed  speech  is  passed  to  the  radio 
simulation  software,  which  packs  it  into  Signal  PDUs  (of  the 
radio  simulation  protocol)  along  with  information  about  the 
current  state  of  the  local  radio  (frequency,  hopset,  mode, 
etc.).  These  are  passed  to  the  Ethernet  interface,  which 
broadcasts  the  speech  signals  onto  the  simulation  network. 

Meanwhile,  other  SINCGARS  radios  on  the  simulation 
network  are  listening  for  Signal  PDUs  on  the  simulation 
network.  These  PDUs  are  picked  up  by  the  Ethernet  interface 
and  passed  to  the  radio  simulation,  which  consults  the 
propagation  model  to  determine  whether  any  of  the  local 
radios  can  hear  the  transmitter.  If  appropriate,  the 
digitized  and  compressed  speech  signal  is  passed  to  the 
speech  I/O  subsystem.  The  SIMVAD  board  decompresses  the 
speech  signal  and  converts  it  from  digital  to  analog  format 
before  passing  it  on  to  the  amplifiers  and  the  speaker,  where 
it  can  be  heard  by  the  listener. 
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Data  Flow  Through  the  SIMCGARS  RIU  Simulator 


The  SINCGARS  simulator  is  not  capable  of  generating  data 
to  be  transmitted.  It  merely  serves  as  the  medium  by  which 
data  are  communicated  between  simulators  such  as  CCD,  which 
are  capable  of  generating  data. 

Data  generated  by  a  CCD  simulator  are  packaged  into 
Transmit  Request  PDUs  and  broadcast  on  the  simulation 
network.  The  SINCGARS  simulator  belonging  to  the  same 
vehicle  ns  the  CCD  simulator  picks  up  the  Transmit  Request 
PDUs  at  the  Ethernet  interface  and  passes  them  to  the  RIU 
simulation.  The  RIU  simulation  resends  the  data  to  the 
simulation  necwork  using  the  RIU-to-RIU  unreliable  broadcast 
protocol . 

Meanwhile,  other  SINCGARS  simulators  are  listening  for 
the  RIU  PDUs.  The  RIU  PDUs  are  picked  up  at  the  Ethernet 
interface  and  sent  to  the  RIU  simulation.  If  the  RIU  is 
using  the  same  command  net  as  the  originator,  the  data  are 
copied  into  a  Receive  PDU  and  rebroadcast  on  the  simulation 
network.  The  Receive  PDU  is  then  picked  up  by  the  CCD 
associated  with  this  RIU  and  the  data  are  passed  to  the 
appropriate  modules  in  the  CCD  simulator.  See  the  section 
describing  Data  communications  with  SINCGARS  for  a  more 
complete  description  of  the  CVCC  Protocols  which  supports 
this  process.  Figure  10  shows  this  data  flow. 


BnTOC  Workstation  and  CCD  Simulations 


This  section  describes  the  hardware  and  software 
architecture  of  the  BnTOC  workstation  and  CCD  simulations. 
They  are  considered  here  together  because  they  share  many  of 
the  same  functional  capabilities  and  software  modules.  The 
section  begins  with  a  discussion  of  the  hardware  architecture 
for  each  simulation.  Then  the  software  architecture  and 
capabilities  are  described,  first  for  the  shared  modules, 
then  for  the  modules  that  are  specific  to  the  BnTOC 
workstation  simulation,  next  for  the  modules  that  are 
specific  to  the  CCD  simulation,  and  finally  for  modules  that 
are  partially  duplicated  in  the  two  simulations. 
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The  BnTOC  workstation  runs  on  the  Sun  SPARC<®  family  of 
processors  (see  Figure  11),  specifically,  the  SPARC  1  and  the 
SPARC  IPX.  BnTOC  is  divided  into  the  host  processor  and  two 
major  subsystems.  These  systems  are  connected  to  the  host 
processor  via  a  bus  network  (the  network  carrying  signal.s 
between  the  subsystems  in  one  workstation) .  The  subsystems 
are: 


•  I/O  subsystem 

•  Ethernet  subsystem 

The  I/O  subsystem  supports  the  user  interface.  It 
consists  of  a  three-button  optical  mouse,  a  keyboard,  and  two 
video  heads.  The  mouse  and  the  keyboard  are  input  devices  for 
interacting  with  the  application.  The  mouse  is  used  to 
position  the  cursor  in  the  graphical  user  interface  (GUI) ,  and 
the  keyboard  is  used  to  input  text.  The  video  heads  are  the 
output  devices  used  to  display  the  user  interface.  Each  video 
head  consists  of  a  19-inch,  color  CRT  monitor  and  a  frame 
buffer  video  driver.  The  monitors  have  a  resolution  of  1152  x 
900  pixels,  and  the  frame  buffers  support  8-bit  pseudo  color. 
This  means  that  at  any  time,  256  colors  are  available  from  a 
total  of  2**24  (approximately  4  million)  possible  colors.  One 
of  the  video  heads  (usually  the  left  one)  is  dedicated  to 
displaying  the  tactical  map.  The  second  video  head  displays 
the  rest  of  the  BnTOC  workstation's  user  interface.  Although 
the  BnTOC  workstation  is  designed  to  run  on  a  two-headed  host, 
it  is  capable  of  running  on  a  single-headed  host  as  well. 

The  Ethernet  subsystem  is  an  Ethernet  board  that  connects 
the  BnTOC  simulation  directly  to  the  simulation  network.  The 
BnTOC  listens  directly  to  the  simulation  network  for  packets. 
The  BnTOC  hosts  contain  a  software  driver  for  reading 
simulation  packets.  Each  BnTOC  application  determines  which 
packets  it  needs  and  throws  away  the  rest. 

CCD  Hardware  Architecture 

The  CCD  simulation  runs  on  the  Sun  SP/UlC  family  of 
processors  (see  Figure  12),  specifically,  the  SPARC  IPX.  The 
CCD  is  divided  into  the  the  host  processor  and  three  major 
subsystems : 

•  commander's  I/O  subsystem 

•  driver's  I/O  subsystem 
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Ethernet  subsystem 


The  CQitimanderJs  I/Q  subsystem  consists  of  a  single  video 
head,  a  touch  screen,  and  a  thumb  controller  on  the 
commander's  control  handle.  The  video  head  is  the  output 
device  for  the  application.  It  consists  of  a  CRT  monitor, 
which  is  part  of  the  CCD  in  the  commander's  station,  and  a 
frame  buffer  video  board  in  the  host  computer.  The  monitor 
is  a  13-inch,  high-resolution  (1250  x  1024  pixels)  color 
monitor.  The  frame  buffer  is  the  seime  as  the  ones  used  in 
the  BnTOC  workstation. 

The  touch  screen  and  thumb  controller  are  used  in  place 
of  an  optical  mouse  for  interacting  with  the  simulation's 
GUI.  The  touch  screen  is  a  pressure-sensitive  touch  screen 
from  Biographies.  When  the  screen  registers  a  touch,  it 
starts  sending  analog  signals  to  a  board  that  converts  them 
to  a  digital  signal.  This  board  interfaces  to  the  host 
computer  over  a  serial  RS-232  connection.  The  digital  output 
is  picked  up  by  the  CCD  software  and  used  to  move  the  cursor. 
Since  the  touch  screen  is  used  in  place  of  a  mouse  input 
device,  touching  the  screen  and  removing  one's  touch  from  the 
screen  have  the  same  effect  as  pressing  and  releasing  a  mouse 
button. 

The  thumb  controller  is  mounted  on  the  commander's 
control  handle.  It  is  a  variable  resistance  button  that 
operates  in  three  planes  of  motion.  Moving  the  button  to  the 
left  and  right  (X  direction) ,  and  up  and  down  (Y  direction) 
controls  the  cursor  on  the  video  display.  Pushing  the  button 
has  the  same  effect  as  clicking  on  a  mouse  button.  Operating 
the  thumb  controller  causes  an  analog  signal  to  be  sent  to  an 
Analog  to  Digital/Digital  to  Analog  Converter  (known  as  an 
ADDA  board)  in  the  host  computer.  The  ADDA  board  samples  the 
analog  connection  at  least  5  times  a  second  and  converts  the 
analog  signal  to  digital  form.  The  CCD  software  on  the  host 
processor  reads  this  digital  output,  using  it  to  drive  the 
cursor  on  the  video  display. 

The  driver's  I/O  subsystem  consists  of  the  soft  panel  in 
the  driver's  compartment,  a  PC  that  drives  the  soft  panel, 
and  an  F.S-232  connection  from  the  PC  to  the  host  computer. 

The  CCD  application  sends  information  about  where  the  driver 
must  go  next  over  the  RS-232  connection.  The  PC  interprets 
this  information  and  displays  it  on  the  soft  panel  in  the 
driver ' s  compartment . 
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Host  Computer  (SPARC  IPX)  aTV/CVCC 
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The  Ethernet  subsystem  is  an  Ethernet  board  that 
connects  the  CCD  simulation  directly  to  the  simulation 
network.  The  CCD  listens  directly  to  the  simulation  network 
for  packets.  The  CCD  hosts  contain  a  software  driver  for 
reading  simulation  packets.  Each  CCD  application  determines 
which  packets  it  needs  and  throws  away  the  rest. 

BnTOC  Workstation  and  CCD  .Software 
Architecture  and  Capabilities 

This  section  describes  the  architecture  and  functional 
capabilities  of  the  BnTOC  Workstation  and  the  CCD  simulation 
software.  The  BnTOC  and  the  CCD  simulations  share  a  common 
software  architecture  and  many  of  the  same  software  modules. 
In  this  way,  the  two  systems  provide  a  similar  set  of 
functional  capabilities  while  minimizing  the  amount  of 
software  required.  The  modules  in  this  architecture  can  be 
divided  into  the  following  four  categories: 

•  shared  —  modules  used  by  both  systems.  The  shared 
modules  constitute  approximately  60%  of  the  total 
lines  of  code  in  the  two  systems  and  provide 
approximately  75%  of  the  functional  capabilities. 

They  include  the  following: 

*  Map  Module 

*  Vehicle  S..atus  Module 

*  Task  Organization  and  Operational  Effectiveness 
(TOOE)  Module 

*  Position  Navigation  (POSNAV)  Module 

*  Report  Module 

*  Fire  Support  Module 

*  Exercise  Control  Module 

*  Configuration  Module 

*  Communications  Module 

Some  shared  modules  have  extended  capabilities  that 
are  available  in  only  one  of  the  systems.  For 
example,  the  concept-of-operations  capabilities  of  the 
Overlay  Module  are  available  only  in  the  BnTOC 
Workstation.  Similarly,  the  Own  Vehicle  Status 
Submodule  of  the  Vehicle  Status  Module  is  an  extension 
used  only  by  CCD.  Also,  although  the  Navigation 
Module  depends  heavily  on  the  shared  capabilities  of 
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(:h«  Report  Module,  the  Navigation  Module  itself  is 
used  only  by  CCD. 

*  IjyiTQC-speqif ic  “•  modules  that  provide  capabilities 
unique  to  the  BnTOC  Workstation.  These  include  the 
following: 

*  Concopt-of-Operations  extension  to  the  Overlay 
Module 

*  Format  Module 

—  modules  that  provide  capabilities 
unique  to  the  CCD  simulation.  These  include  the 
following: 

*  Own  Vehicle  Status  Submodule  of  the  Vehicle  Status 
Module 

*  Navigation  Module 

•  Duplicated  --  modules  that  provide  similar,  but  not 
identical  capabilities,  and  are  therefore  used  in 
slightly  different  form  in  each  application.  The 
duplicated  modules  include  the  following: 

*  Instrumentation  Module 

*  User  interface 

The  following  four  sections  describe  the  modules  in  each 
of  the  above  categories.  For  the  shared  modules,  differences 
between  the  BnTOC  and  CCD  capabilities  are  noted  in 
parentheses.  For  the  duplicated  modules,  comparisons  are 
drawn  between  the  BnTOC  and  CCD  implementations. 


Shared,, ModuJLgg 


The  Map  Module  provides  the  BnTOC  workstations  and  the 
CCD  simulators  with  the  ability  to  display  and  manipulate  a 
two-dimensional  map  of  the  battlefield.  Elements  of  the 
tactical  map  include  terrain  features,  graphical  overlays, 
report  icons,  and  friendly  vehicle  (POSNAV)  icons. 

Operations  that  can  be  performed  on  the  map  include  posting 
and  unposting  map  elements,  scrolling  the  map,  and  scaling 
the  map.  These  elements  and  operations  are  described  below. 

Terrain  features  —  The  tactical  map  can  display 
contour  lines,  grid  lines,  rivers,  roads,  and 
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vegetation.  The  user  can  display  or  suppress  display 
of  individual  terrain  features.  These  terrain 
features  are  described  in  the  terrain  database.  The 
terrain  database  most  commonly  used  by  the  CVCC 
software  corresponds  to  a  50  x  75  kilometer  region 
around  Ft.  Knox,  Kentucky, 

•  Graphical  overlays  —  The  tactical  map  can  display 
graphical  overlays  such  as  Operations,  Enemy  Situation 
and  Fire  Support  Overlays,  which  are  composed  of 
symbols  defined  in  FM  101-5-1  Operational  Terms  and 
Symbols  (U.S.  Army,  1985).  These  overlays  are 
arranged  in  a  stack  The  stacking  order  can  be 
rearranged  by  using  the  stacking  commands.  The 
overlays  can  be  edited  (BnTOC  only) ,  sent  to  other 
simulators,  and  received  from  other  simulators  (CCD 
only) .  (See  the  section  describing  the  Overlay  Module 
for  more  information.) 

•  Report  icons  —  The  tactical  map  can  display  icons 
relating  to  standard  Army  reports  such  as  Spot  reports 
and  Contact  reports.  The  user  can  view  the  associated 
reports  by  selecting  the  report  icons.  (See  the 
section  describing  the  Report  Module  for  more 
information. ) 

•  Friendly  vehicle  (POSNAV)  icons  -  The  tactical  map  can 
display  and  update  friendly  vehicle  icons  based  on  the 
positional  NAVigation  (POSNAV)  information  received 
from  operational  CCDs.  To  show  the  current  location 
of  the  battalion's  combat  vehicles,  these  POSNAV  icons 
can  be  aggregated  and  de-aggregated  to  any  level  of 
aggregation,  from  individual  vehicles  to  the  entire 
battalion.  (See  the  section  describing  the  Position 
Navigation  Module  for  an  explanation  of  the  center-of- 
mass  algorithm  used  to  aggregate.) 

•  Scrolling  —  The  user  can  scroll  the  tactical  map  to 
any  location  on  the  terrain  database, 

•  Scaling  —  The  user  can  display  the  tactical  map  at  the 
following  map  scales:  1:250,000;  1:125,000;  1:50,000; 
1:25,000. 

The  Map  Module  is  also  used  to  implement  the  electronic 
Situation  Display  in  the  Battalion  TOC  area.  The  Situation 
Display  is  a  special  tactical  map  that  serves  as  a  central 
planning  tool.  It  is  connected  to  a  large-screen  monitor  so 
that  everyone  in  the  TOC  can  observe  it.  All  other  TOC 
workstations  can  post  and  unpost  their  own  overlays  and 
report  icons  to  the  Situation  Display.  All  CCD-equipped 
vehicle  locations  are  displayed  in  real  time  here  as  well. 
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The  Map  Module  architecture  consists  of  the  follov/ing 
submodules  (see  Figure  13): 

•  Color  System  Submodule  —  provides  the  primitives  for 
controlling  which  colors  are  used  for  which  features 
and  symbols  on  the  tactical  map  display.  The  Color 
System  uses  a  technique  known  as  "bit  planes, "  which 
limits  the  number  of  colors  available  for  drawing  in 
order  to  establish  two  independent  and  overlapping 
drawing  planes.  This  allows  the  Map  Module  to  alter 
the  contents  of  one  of  the  planes  without  disturbing 
the  contents  of  the  other.  The  Map  Module  dedicates 
the  bottom  plane  for  use  by  the  Terrain  Library 
(terrain  features)  and  the  top  plane  for  use  by  the 
Symbol  Library  (overlays,  report  icons,  and  POSNAV 
icons) .  In  this  way,  the  need  to  redraw  the  map  is 
minimized  at  the  cost  of  significantly  limiting  the 
number  of  colors  available. 


Map  Viewport 

Map  La3«rs 

Terrain 

Library 

Symbol 

Library 

Color  System 

Teriiain 
I  Database  I 


Figure  13.  Map  module. 


The  use  of  colors  in  the  Color  System  Submodule  has 
been  parameterized  in  order  to  facilitate 
reconfiguring  the  system.  The  features  which  have 
been  parameterized  are  listed  in  Table  1  together  with 
their  default  values: 
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Table  1 


Terrain  Library  Features 


Terrain 

Default  Color 

Terrain  background 

Wheat 

Buildings 

Black 

Fordable  water 

SkyBlue 

Non- fordable  water 

Blue 

FlOcids 

Red 

Vegetation 

Fores tGreen 

Low  contour  lines 

Black 

High  contour  lines 

Black 

Grid  lines 

Black 

The  colors  used  by  the  Color  System  Submodule  may  be 
configured  by  the  user  in  the  "Bntoc"  or  "CCD" 
xresource  file.  The  available  list  of  named  colors  to 
which  the  features  may  be  set  is  located  in  the  file 
/usr/openwin/lib/rgb.  txt  (use  the  capitalized  neimes)  . 

The  default  settings  can  be  overridden  at  runtime 
using  the  parameters  stimmarized  in  Table  3  in  Appendix 
C. 

•  Terrain  Library  Submoduls  —  provides  the  capabilities 
for  drawing  the  terrain  features  (grid  lines,  contour 
lines,  roads,  rivers,  and  vegetation)  on  the  tactical 
map.  The  Terrain  Library  reads  information  about  the 
terrain  features  from  a  specially  formatted  (object- 
oriented,  quad-tree)  database  that  is  prepared  from 
Level  I  Defense  Mapping  Agency  (DMA)  data  (see  the 
section  describing  terrain  databases) .  The 
information  read  from  the  "terrain  database"  is  drawn 
on  the  tactical  map  using  the  terrain  plane  of  the 
Color  System  submodule. 

•  Symbol  Library  Submodule  —  provides  the  primitives  needed 
by  the  Map  Module  to  draw  overlays,  POSNAV  icons,  and 
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report  icons ,  The  Symbol  Library  Submodule  provides  the 
primitives  for  drawing  a  large  subset  of  the  symbols 
defined  in  FM  101-5-1  Operational  Terms  .■.aad.,,Simb.Qls, 
including  control  measures  (such  as  phase  lines,  front 
lines  of  troops  (PLOT),  and  restrictive  fire  areas),  unit 
symbols  (such  as  armored  units  and  mechanized  infantry 
units) ,  and  point  symbols  (such  as  waypoints,  control 
points,  and  target  reference  points  (TRPs) ) .  In 
addition,  the  Symbol  Library  Submodule  provides  the 
primitives  for  drawing  the  symbols  used  in  standard  Army 
reports  (such  as  target  locations  and  observer 
locations) . 

•  Map  Layers  Submodule  —  groups  the  symbols  (POSNAV  icons, 
report  icons,  and  overlay  symbols)  in  the  Symbol 
Library’s  drawing  plane  into  a  stack  of  layers.  It  forms 
the  basis  of  the  overlay  stacking  capabilities,  since  the 
Map  Module  places  each  overlay  displayed  on  the  map  in  a 
separate  layer.  The  Map  Layers  Submodule  controls  what 
layers  are  sensitive  to  direct  manipulation  by  the  user, 
thus  controlling  which  overlay  on  the  tactical  map  ceui  be 
edited  in  edit  mode.  (Note  that  overlays  can  only  be 
edited  in  the  BnTOC  workstation.)  The  Map  Module  places 
the  POSNAV  icons  and  the  report  icons  in  two  special- 
purpose  layers  at  the  bottom  of  the  stack  of  layers . 

•  Map  Viewport  Submodule  —  maintains  a  "window- on- the- 
world"  view  of  the  terrain.  It  provides  the  scrolling 
and  scaling  capabilities  required  to  manipulate  this 
view. 

Overlay  module . 

The  Overlay  Module  enables  the  user  to  perform  the 
following  operations  on  the  graphical  overlays  on  the 
tactical  map: 

•  Edit  (BnTOC  Workstation  only)  —  The  user  cein  edit 
graphical  overlays  such  as  Operations  and  Fire  Support 
Overlays,  which  are  composed  of  symbols  defined  in  FM 
101-5-1  Operational  Terms  and  Symbols. 

•  Send  —  The  user  at  each  BnTOC  Workstation  can  send 
overlays  to  the  CCDs  and  copy  overlays  from  any  of  the 
other  BnTOC  Workstations  on  the  BnTOC  network.  The 
CCDs  can  also  forward  overlays  to  each  other. 

•  Receive  —  The  CCDs  can  receive  overlays  from  all  BnTOC 
workstations  and  from  other  CCDs . 
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•  Copy  —  The  user  at  each  BnTOC  Workstation  can  copy 
overlays  from  any  of  the  other  BnTOC  Workstations  on 
the  BnTOC  network. 

•  Post  —  The  user  can  post  overlays  to  and  unpost 
overlays  from  the  tactical  map.  The  user  can  post  any 
number  of  overlays  simultaneously.  BnTOC  users  have 
the  additional  capability  of  posting  overlays  to  and 
unposting  overlays  from  the  Situation  Display.  The 
user  at  each  BnTOC  Workstation  can  view  and  copy 
formats  from  any  of  the  other  BnTOC  Workstations  on 
the  BnTOC  network. 

The  architecture  of  the  Overlay  Module  consists  of  one 
submodule  (see  Figure  14) : 

•  Overlay  Manipulation  Submodule  —  implements  the 
capabilities  listed  above. 


Overlay 

Manipulation 

Concept  of 
Operations 

Overlay  Database  Interface 

Figure  14.  Overlay  and  Concept-of-Operations  module. 


Vehicle  Status  module. 

The  Vehicle  Status  module  handles  all  aspects  of  vehicle 
status  information,  including  sending  own  vehicle  status, 
forwarding  the  status  of  other  vehicles,  receiving  the  status 
of  other  vehicles,  emd  dispatching  this  status  information  to 
the  appropriate  modules  for  processing.  This  vehicle  status 
information  includes  POSNAV  information  (vehicle  location) 
and  operational  effectiveness  information  (status  of 
ammunition,  equipment,  fuel,  and  personnel) . 

The  Vehicle  Status  Module  architecture  consists  of  two 
submodules  (see  Figure  15) . 
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•  Aggregate  Status  Submodule  ~  dispatches  vehicle  status 
data  from  the  Communications  Module  to  the  correct 
modules  for  processing.  Operational  effectiveness 
information  about  fuel,  ammunition,  equipment,  and 
personnel  is  sent  to  the  Task  Organization  and 
Operational  Effectiveness  Module,  whereas  POSNAV  data 
are  sent  to  the  Position  Navigation  Module.  In  CCD 
simulators,  the  Aggregate  Status  Submodule  sends  its 
own  vehicle's  location  and  operational  effectiveness 
status  to  other  CCD  simulators  on  its  command  network. 
In  CCD  simulators  playing  the  role  of  a  unit  leader 
(i.e.,  Company  CO,  Con^any  XO,  Platoon  Leader,  or 
Platoon  Sergeant) ,  the  Aggregate  Status  Submodule 
forwards  the  status  of  the  vehicles  in  its  unit  to  its 
superior  command  network.  Likewise,  it  forwards 
vehicle  status  information  found  on  its  superior 
command  network  down  to  the  vehicles  in  its  own 
command  network.  In  this  way,  each  vehicle  in  the 
CVCC  armor  battalion  is  kept  informed  about  every 
other  vehicle  in  the  battalion. 


TOOE  Module  POSNAV  Module 


Vehicle  Status  Module 


Figure  15.  Task  Organization/Operational  Effectiveness, 
POSNAV,  and  Vehicle  Status  modules. 

Task  Organization  and  _C>peratiQnal  Effectiveness  (TOPE) 

module . 

The  Task  Organization  and  Operational  Effectiveness 
(TOOE)  Module  enables  the  user  to  display  the  current 
operational  effectiveness  status  of  the  vehicles  in  the  CVCC 
armor  battalion.  The  TOOE  defines  the  task  organization 
hierarchy  for  the  CVCC  armor  battalion  and  keeps  an  updated 


49 


accounting  of  thd  operational  effectiveness  of  vehicles  and 
units  in  the  battalion,  including  the  status  of  eunmunition, 
equipment,  fuel,  and  personnel.  This  status  is  continually 
updated  using  status  reports  received  from  the  CCD  simulators 
in  the  individual  tanks.  The  operational  ef fectivenes.s 
status  con  be  displayed  to  any  level  of  aggregation,  from 
individual  vehicles  to  the  entire  armor  battalion,  based  on 
the  task  organization.  The  status  is  displayed  in  bar-graph 
format  and  in  the  ammunition,  equipment,  fuel,  and  personnel 
circle  chart  format  shown  in  FM  101-5-1  and  the  effectiveness 
levels  are  color-coded  green,  yellow,  red,  and  black. 

Personnel  is  a  placeholder  and  is  currently  always  green. 

The  TOOK  module  architecture  consists  of  three 
submodules  (see  Figure  15) . 

•  Task  Organization  (TO)  Hierarchy  Submodule  —  maintains 
the  task  organization  of  the  CVCC  armor  battalion  in 
the  form  of  a  tree  structure  (an  organizational  chart) 
that  captures  superior/ subordinate  reporting 
relationships,  as  well  as  unit  and  subunit 
composition.  This  information  is  read  into  the  system 
from  the  task  organization  configuration  file  at 
startup  cind  is  considered  to  be  static  during  runtime. 
In  the  course  of  an  exercise,  the  Task  Organization 
Hierarchy  receives  information  from  the  Vehicle  Status 
module  about  the  operational  effectiveness  (OE)  of  the 
individual  vehicles  in  the  CVCC  armor  battalion.  It 
uses  this  information  to  generate  OE  status 
information  for  the  various  units  in  the  battalion. 

•  Operational  Effectiveness  (OE)  Reports  Submodule  — 
controls  the  formatting  of  the  OE  reports,  including; 
drawing  individual  bar  graphs  and  their  labels, 
positioning  multiple  bar  graphs  within  a  single 
report,  and  displaying  OE  status  using  the  circle 
chart  convention. 

•  TOOE  Display  Submodule  —  accesses  the  OE  status 
information  in  the  Task  Organization  Hierarchy 
Submodule  and  uses  the  drawing  primitives  in  the  OE 
Reports  Submodule  to  display  the  operational 
effectiveness  of  any  unit  in  the  CVCC  armor  battalion 
as  required  by  the  user.  Any  TOOE  Reports  being 
displayed  by  the  user  are  updated  periodically  from 
the  latest  data  in  the  TO  hierarchy.  The  default 
period  for  TOOE  refresh  is  30  seconds.  This  may  be 
adjusted  by  setting  the  tooeSecsPerUpdate  resource  in 
the  "BnToc"  xresource  file. 


50 


£aaitiQn,  Naviaatign  ( PQSNAV.) ,  -module  • 


The  Position  Navigation  (POSNAV)  Module  controls  the 
display  of  POSNAV  icons,  which  indicate  the  current  locations 
of  vehicles  and  units  on  the  tactical  map.  The  POSNAV  icons 
can  be  displayed  to  any  level  of  aggregation,  from  individual 
vehicles  to  the  entire  armor  battalion.  The  POSNAV  Module 
continually  updates  the  locations  of  the  vehicles  of  the 
battalion,  based  on  reports  received  from  the  CCDs  in  the 
individual  tanks.  The  POSNAV  Module  uses  this  information  to 
calculate  and  display  the  unit  locations  for  all  the  platoons 
and  conpanies  in  the  battalion,  as  well  as  for  the  CVCC  armor 
battalion  itself.  Unit  locations  are  based  on  a  "center-of- 
mass"  algorithm.  The  center-of-mass  algorithm  computes  the 
weighted  average  location  of  all  vehicles  in  a  unit;  once  the 
center-of-mass  has  been  calculated,  vehicles  outside  a 
prescribed  radius  are  identified  as  outliers;  the  center-of- 
mass  is  then  recalculated,  omitting  the  location  of  outliers 
from  the  calculation.  In  this  way,  damaged  or  destroyed 
vehicles  do  not  skew  the  center-of-mass  calculations. 

The  radius  that  controls  the  definition  of  outliers  can  be 
set  differently  for  each  level  of  aggregation.  Table  2 
lists  unit  levels  and  the  default  distance  setting  in  meters 
from  the  center-of-mass  beyond  which  vehicles  are  considered 
outliers: 


Table  2 

Default  Distance  Setting  in  Meters  From  the  Center-of-Mass 
Beyond  Which  Vehicles  Are  considered  Outliers,  According  to 
Unit  Level 


Unit  Level 

Default 

Distance 

Section 

750 

Platoon 

750 

Company 

1750 

Battalion 

5000 
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These  default  settings  can  be  overridden  at  runtime 
using  the  parameters  summarized  in  Table  5  of  Appendix  C. 

The  POSNAV  Module  architecture  consists  of  the  following 
two  submodules  (see  Figure  15) : 

•  POSNAV  Hierarchy  Submodule  —  maintains  information  on 
the  current  location  of  vehicles  and  units  in  a  form 
similar  to  the  TOOK  hierarchy.  However,  whereas  the 
TO  hierarchy  is  static,  the  POSNAV  hierarchy  is 
dynamic  and  reflects  only  vehicles  that  are  currently 
reporting  their  locations.  Destroyed  vehicles  are  not 
reflected  in  the  POSNAV  hierarchy.  In  the  course  of 
an  exercise,  the  POSNAV  Hierarchy  Submodule  receives 
information  from  the  Vehicle  Status  Module  about  the 
locations  of  individual  vehicles  in  the  CVCC  armor 
battalion.  The  POSNAV  Hierarchy  Submodule  uses  this 
information  periodically  to  regenerate  the  locations 
of  the  units  in  the  battalion  based  on  a  center-of- 
mass  algorithm.  Vehicles  that  do  not  report  their 
location  before  the  POSNAV  timeout  are  also  considered 
destroyed  and  are  not  considered  in  the  POSNAV 
hierarchy. 

•  POSNAV  Display  —  displays  the  POSNAV  icons  on  the 
tactical  map  and  updates  them  in  response  to  the 
latest  information  about  vehicle  and  unit  location 
contained  in  the  POSNAV  Hierarchy  Submodule.  To 
control  the  amount  of  redrawing  required,  the  POSNAV 
Display  Submodule  updates  the  POSNAV  icons  on  the  map 
from  the  latest  information  in  the  hierarchy  every  10 
seconds.  The  POSNAV  Display  Submodule  also  reacts  to 
user  commands  to  change  the  aggregation  levels  of  the 
POSNAV  icons  displayed  on  the  tactical  map. 

Re, ooxt.  ..module  • 

The  Report  Module  enables  the  user  to  edit,  send, 
receive,  store,  organize,  display,  and  post  formatted  Army 
reports,  including  Adjust  Fire  reports.  Call -For-Fire 
reports.  Contact  reports.  Free  Text  reports,  Intel  reports, 

NBC  reports,  Shell  reports,  SitRep  reports,  and  Spot  reports. 
The  Navigation  Module,  a  CCD-specific  extension  to  the  Report 
Module,  is  described  after  the  Report  Module. 

•  Edit  —  The  Report  Module  enables  the  user  to  edit  the 
formatted  Army  reports  listed  above  (with  the 
exception  of  Free  Text  Reports) . 

In  the  CCD,  the  CITV  Laser  Range  Finder  can  be  used  to 
fill  in  report  locations.  As  mentioned  in  the  section 
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doscribing  data  collection  protocol,  the  CCD  does  this 
by  listening  for  CITV  status  packets  belonging  to  the 
data  collection  protocol  which  are  sent  by  the 
associate  vehicle  simulator. 

•  Send  and  receive  —  The  Report  Module  enables  the  user 
to  send  and  receive  the  formatted  Army  reports  listed 
above  (with  the  exception  of  Free  Text  reports)  on  the 
various  platoon,  company,  and  battalion  command 
networks  as  defined  by  standard  Army  practice. 

•  Filter  “  Users  of  the  BnTOC  Workstations  can  filter 
out  report  types  that  do  not  interest  them. 

•  Aggregate  —  When  the  Report  Module  receives  a  Spot 
report.  Contact  report,  or  Shell  report,  it  checks  the 
list  of  reports  that  have  not  yet  been  acted  on  for 
those  that  refer  to  the  same  battlefield  event.  Two 
reports  are  considered  to  refer  to  the  seutie 
battlefield  event  if  they  occurred  in  "close 
proximity"  in  terms  of  time  and  distance.  The  default 
definition  of  "close  proximity"  is  5  minutes  and  1 
kilometer.  Two  reports  that  are  deemed  to  refer  to 
the  same  battlefield  event  are  aggregated  into  a 
single  report  containing  the  weighted  average  of  the 
two  reports  in  terms  of  time,  distance,  and  numbers  of 
objects  observed.  The  original  reports  are  replaced 
by  the  new  aggregate  report;  however,  they  are  not 
deleted.  Rather,  they  are  attached  to  the  aggregate 
report  and  can  be  read  by  the  operator  if  so  desired. 
In  this  way,  sightings  of  the  same  battlefield  event 
by  independent  observers  will  be  aggregated  into  a 
single  report,  easing  the  operator's  work  load. 

•  Store  —  The  Report  Module  stores  newly  created  and 
newly  received  reports  into  the  Report  Database.  Each 
report  has  a  unique  identifier  and  is  tagged  with 
pertinent  information  such  as  the  creation  time,  the 
arrival  time,  the  recipient  to  whom  the  report  was 
forwarded,  and  whether  or  not  the  report  is  currently 
posted. 

•  Organize  —  The  Report  Module  enables  the  user  to 
organize  the  reports  into  groups,  or  "folders."  In 
the  BnTOC,  reports  are  placed  in  a  receive  queue  as 
they  are  received.  BnTOC  users  can  create  and  delete 
folders  to  customize  their  filing  scheme,  the  so- 
called  Workbook.  Reports  are  not  automatically 
grouped  into  folders  once  they  have  been  viewed; 
action  must  be  taken  on  reports  to  place  them  in 
workbook  folders,  or  they  age  into  a  Miscellaneous 
Folder.  However,  viewed  reports  are  automatically 
maintained  in  a  special  Journal  folder,  which 
provides  the  capabilities  of  the  standard  Army  report 
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journal.  Users  can  view  the  contents  of  Workbooks  and 
Journals  located  at  any  of  the  BnTOC  Workstations  on 
the  BnTOC  network. 

CCD  users  have  a  less  flexible  organization  scheme. 
Reports  are  placed  in  a  receive  queue  as  they  are 
received  from  the  communications  networks.  After  they 
have  been  viewed,  reports  are  automatically  grouped 
into  folders  by  report  type. 

•  Display  and  post  —  The  Report  Module  enables  the  user 
to  display  reports  received.  Icons  corresponding  to 
the  critical  battlefield  locations  contained  in  the 
report  are  displayed  on  the  tactical  map  while  the 
reports  are  being  displayed.  For  example,  the  target 
locations  and  target  types  contained  in  Contact 
reports  are  displayed  on  the  tactical  map.  Report 
icons  can  be  posted  to  the  tactical  map  permanently  or 
until  explicitly  removed  by  the  user.  BnTOC  users 
have  the  additional  capability  of  posting  reports  to 
and  unposting  reports  from  the  TOC  Situation  Display. 

The  Report  Module  consists  of  the  following  submodules 
(see  Figure  16) : 

•  Report  Database  Interface  Submodule  —  provides  the 
report  storage  capabilities  described  above. 

•  Report  Manipulation  Submodule  —  provides  the 
capability  to  edit,  send  and  receive,  aggregate, 
filter,  and  post  reports. 

•  Report  Folders  Submodule  —  provides  the  capability  to 
organize  reports  into  folders.  In  the  BnTOC,  this  is 
used  to  implement  the  Workbook  and  Journal .  In  the 
CCD,  it  is  used  to  implement  the  report-specific 
folders  - 

•  Report  Display  Submodule  —  provides  the  capability  to 
display  folders  and  reports,  and  presents  all  the 
other  capabilities  to  the  user  in  a  unified  graphical 
user  interface. 
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Fire  Support  module. 

The  Fire  Support  Module  provides  support  for  editing  and 
viewing  Call-For-Fire  reports.  Target  locations  can  be 
specified  using  either  Target  Reference  Points  (TRPs)  from 
Fire  Support  Overlays  or  UTM  coordinates  when  composing  Call- 
For-Fire  reports. 

The  Fire  Support  module  does  not  have  architectural 
submodules . 


Exercise  Control  module. 

The  Exercise  Control  Module  provides  exercise  control 
support  for  running  an  exercise.  It  implements  the 
Checkpoint,  Restart,  and  Shutdown  operations  for  the  BnTOC 
Workstation  and  CCD  simulation.  In  addition,  the  Exercise 
Control  Module  provides  the  capability  of  initiating  these 
operations,  from  a  single  point  of  control,  by  convention, 
one  of  the  BnTOC  workstations.  The  Checkpoint  operation 
causes  BnTOC  Workstations  and  CCD  simulations  to  save  their 
current  state  under  a  user-specified  identifier  so  that  they 
can  be  recovered  later.  The  Restart  operation  recovers  the 
specified  state  previously  saved  in  a  Checkpoint  operation. 
The  Checkpoint /Restart  combination  allows  an  exercise  to  be 
suspended  for  any  amount  of  time  and  then  continued  with  no 
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negative  effect.  The  Shutdown  operation  causes  the  BnTOC 
Workstation  and  the  CCD  simulation  to  exit. 

The  Exercise  Control  Module  does  not  have  architectural 
submodules . 

Configuration  module. 

The  Configuration  Module  keeps  track  of  the  call  sign 
and  duty  position  information  for  every  BnTOC  Workstation  and 
CCD  simulator  participating  in  an  exercise  (for  example, 

BnTOC  Workstation  "A"  has  the  call  sign  "YOS"  and  the  duty 
position  of  "battalion  1  commander, "  or  CCD  simulator  "B"  has 
the  call  sign  "A06"  and  the  duty  position  of  "battalion  1, 
company  A  commeinder " )  .  At  startup,  this  information  is  read 
from  a  centralized  network  configuration  file  into  each  BnTOC 
Workstation  and  CCD  simulator  participating  in  the  exercise. 
It  is  updated  over  the  course  of  an  exercise  in  the  unusual 
event  that  a  BnTOC  Workstation  or  CCD  simulator  playing  a 
critical  role  (such  as  the  battalion  commander)  fails  and 
needs  to  be  replaced.  The  BnTOC  Workstations  use  this 
information  to  access  overlays,  folders,  and  formats  on  other 
BnTOC  Workstations  directly  over  the  network. 

The  Configuration  module  does  not  have  architectural 
submodules . 


Communications  module. 

The  Communications  Module  sends  and  receives  data  across 
the  simulation  network  for  the  BnTOC  Workstations  and  CCD 
simulators . 

The  Communications  Module  provides  support  for  the 
following  types  of  data  communications: 

•  Point-to-point  —  for  sending  command  and  control  data 
from  BnTOC  Workstation  to  BnTOC  Workstation.  This 
capability  is  currently  used  for  routing  reports  only. 

•  Radio  multicast  —  through  the  use  of  radio-based 
military  networks  for  CCD-to-CCD,  CCD-to-BnTOC,  and 
BnTOC-to-CCD  command  and  control  data  communications . 
Currently,  the  Communications  Module  provides  support 
for  platoon,  company,  and  battalion  radio  voice  and 
digital  command  nets  for  the  CVCC  armor  battalion, 
with  or  without  the  SINCGARS  radio  simulation. 
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•  Broadcast  —  for  sending  exercise  control  and 

configuration  data  to  all  BnTOC  Workstations  and  CCD 
simulators  participating  in  the  exercise. 

The  Communications  Module  is  implemented  as  a  library 
which  is  used  by  both  the  BnTOC  workstation  and  the  CCD.  The 
architactvire  of  the  Communications  Module  is  divided  into 
three  submodules,  as  depicted  in  Figure  17. 


CCD  or  BnTOC 


Dispatcher 


Broadcast 

Interface 


Radio  Interface 


Simulation  Network  Interface 


Simulation  Network 


Figure  17.  CCD  Communications  module. 


The  Simulation  Network  Interface  submodule  manages  the 
connection  to  the  simulation  network  by  opening  and  closing 
the  network  connection,  providing  routines  for  writing  data 
to  the  simulation  network,  and  providing  a  subscription 
service  for  incoming  packets.  A  subscriber  of  the  Simulation 
Network  interface  may  select  a  protocol  and  (optionally)  a 
kind  of  packet  within  that  protocol,  then  specify  the 
processing  to  be  performed  for  those  selected  packets.  For 
example,  the  BnTOC  would  specify  that  a  shutdown  function 
would  be  run  whenever  a  shutdown  packet  in  the  CVCC  protocol 
is  received. 

The  Radio  Interface  submodule  manages  the  connection 
between  the  CVCC  application  (BnTOC  or  CCD)  and  associated 
SINCGARS  radio  simulator  (when  in  use)  by  communicating  with 
it  via  the  CVCC  protocol.  In  order  to  communicate  with  the 
SINCGARS  simulator,  the  simulation  network  is  accessed 
through  the  Simulation  Network  Interface. 

The  Radio  Interface  uses  the  service^;  of  the  Simulation 
Network  Interface  not  only  to  communicate  with  a  SINCGARS 
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radio  simulator,  but  also  to  provide  a  higher- level  interface 
for  sending  and  receiving  radio  messages. 

The  Radio  Interface  submodule  provides  the  ability  to 
send  messages  point-to-point  or  broadcast  on  a  selected  set 
of  radio  networks.  The  supported  radio  networks  simulate 
military  (command)  networks,  such  as  the  Battalion  Command 
Net  or  Company  A  Command  Net.  The  Radio  Interface  submodule 
provides  this  service  whether  or  not  a  SINCGARS  radio 
simulator  is  being  used  to  simulate  the  transmission  of  the 
messages.  When  a  SINCGARS  radio  simulator  is  not  being  used 
(due  to  its  configuration  or  failure  of  the  radio  simulator) , 
the  Radio  Interface  submodule  automatically  simulates  perfect 
radio  transmission  by  sending  the  information  directly  to  the 
recipients  (via  the  Simulation  Network  Interface  submodule) . 

The  Radio  Interface  submodule  provides  a  subscription 
service  analogous  to  the  service  provided  by  the  Simulation 
Network  Interface  submodule.  The  subscriber  may  specify  what 
processing  should  be  performed  when  a  particular  kind  of 
message  is  received. 

The  Dispatch  Mechanism  submodule  provides  a  generic 
utility  for  providing  subscription  services.  This  submodule 
is  used  by  both  the  Simulation  Network  Interface  submodule 
and  the  Radio  Interface  submodule  to  implement  their 
subscription  services . 


BnTOC- specific  Modules 

Concept-of-Qperations  submodule . 

The  Concept  of  Operations  (COO)  Submodule  is  an 
extension  to  the  Overlay  module  that  is  available  only  on  the 
BnTOC  Workstation.  The  COO  Submodule  enables  the  user  to 
edit  and  display  concept-of-operations  overlays  on  the 
tactical  map.  Concept-of-operations  overlays  consist 
strictly  of  unit  icons  belonging  to  an  organic  task 
organization  hierarchy  such  as  an  armor  battalion.  The  task 
organization  hierarchy  can  be  de-aggregated  to  the  desired 
level,  and  each  of  the  resulting  unit  icons  in  the  task 
organization  can  be  placed  in  a  series  of  battlefield 
locations  corresponding  to  the  unit's  battle  positions  for 
the  various  phases  of  the  operation.  By  stepping  the  unit 
icons  through  their  battle  positions,  the  user  can  reveal  the 
operation  phase  by  phase. 
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FgrmtL.juaduIe- 


The  Format  Module  enables  the  user  to  edit,  store,  and 
display  the  following  standard  Army  formats:  AnalAreaOpns , 
EstSit,  IntelEst,  OpnSit,  OpnsOrd,  Perintel,  PerOpnRpt, 
RoadMvt.  As  a  starting  point  when  editing  a  format,  the  user 
is  provided  with  a  job  aid  template  that  outlines  the 
paragraphs  contained  in  the  format .  The  user  at  each  BnTOC 
Workstation  can  view  and  copy  fofSmats  from  any  of  the  other 
BnTOC  Workstations  on  the  BnTOC  network. 

The  Format  module  does  not  have  architectural 
submodules . 


CCD- spec  l£ic_.  Modules 


Own  Vehicle  Status  submodule  of  Vehicle  Status  module. 

The  Own  Vehicle  Status  Submodule  listens  for  two  types 
of  data  packets  from  its  associate  vehicle  simulator. 

Vehicle  Appearance  packets  belonging  to  the  Simulation 
Protocol  contain  information  about  the  vehicle  location, 
vehicle  heading,  turret  orientation,  and  the  vehicle  status, 
including  fuel  and  ammunition  levels,  and  subsystems  status. 
CITV  Orientation  packets  belonging  to  the  CVCC  protocol 
contain  information  about  the  current  CITV  orientation.  The 
Own  Vehicle  Status  Submodule  uses  this  vehicle  location, 
vehicle  heading,  turret  orientation,  and  CITV  orientation 
information  to  update  the  "own  tank"  icon  on  the  CCD  tactical 
map.  It  passes  the  vehicle  status  information  to  the 
Aggregate  Status  Submodule  to  be  sent  to  other  vehicles . 


Navigation  module. 

The  Navigation  Module  is  an  extension  to  the  Report 
Module  and  is  available  in  the  CCD  simulation  only.  The 
Navigation  Module  enables  the  tank  commander  to  edit,  send, 
receive,  display,  post,  and  store  routes  in  the  form  of  a 
series  of  waypoints.  In  addition,  the  Navigation  Module 
provides  an  interface  for  automatically  sending  to  the  tank 
driver  the  direction  and  distance  to  the  next  waypoint. 

The  Navigation  Module  uses  the  Report  Database 
Interface,  the  Report  Manipulation,  and  the  Report  Folders 
submodules  to  provide  the  capability  to  edit,  send,  receive, 
store,  display,  and  post  routes.  An  extension  to  the  Report 
Manipulation  Submodule  provides  the  capability  to  display 
routes.  The  Navigation  Manipulation  Submodule  supports  the 
interface  to  the  tank  driver. 
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The  Instrume.ntation  Module  provides  the  capability  to 
send  data  about  how  the  users  of  the  BnTOC  Workstation,  CCD, 
and  CITV  are  using  the  systems  to  support  the  data  collection 
requirements  of  the  CVCC  experiments  at  the  MWTB. 
Specifically,  it  supports  sending  PDUs  belonging  to  the 
instrumentation  subprotocol.  (For  more  detailed  information, 
see  the  section  on  the  instrumentation  subprotocol , ) 


User  interface. 

The  user  interface  is  not  a  separate  module.  Rather,  it 
is  distributed  across  a  number  of  different  modules, 
including  the  Map  Module,  the  TOOE  Module,  the  Report  and 
Navigation  Module,  the  Overlay  and  COO  Module,  and  the  Format 
Module.  Each  of  these  modules  contributes  to  the  user 
interface.  However,  because  of  the  differences  in  the 
capabilities  of  the  display  software  and  hardware  used  by  the 
BnTOC  Workstations  and  the  CCD  simulators,  most  of  the  code 
used  to  implement  the  user  interface  is  duplicated  in  the  two 
systems . 


BnTOC  Workstation  and  CCD.,SimulatiQn  Data  Flow 

This  section  presents  a  unified  view  of  the  modules  that 
make  up  the  BnTOC  Workstation  and  the  CCD  simulation.  Since 
the  central  focus  of  the  BnTOC  Workstation  and  CCD  simulation 
is  the  communication,  manipulation,  and  display  of  data,  a 
data  flovz  diagram  (Figure  18)  is  used  to  present  this  unified 
view.  The  discussion  below  follows  the  path  of  a  piece  of 
data  (i.e.,  a  PDU)  from  the  point  at  which  it  enters  the 
system  to  its  final  destination,  where  it  is  processed. 

When  new  PDUs  are  read  by  the  simulation  network 
interface,  they  are  checked  to  see  what  type  of  interface 
they  are  using.  Broadcast  packets  contain  control  data  and 
are  routed  to  the  Broadcast  Interface  of  the  Communications 
Module,  whereas  multicast  packets  contain  command  and  control 
data  and  are  routed  to  the  Radio  Interface. 

Packets  arriving  at  the  Broadcast  Interface  are  passed 
to  the  Dispatcher,  which  checks  what  type  of  control  data  the 
packet  contains.  Exercise  control  data  (i.e..  Checkpoint, 
Restart,  and  Shutdown  commands)  are  passed  to  the  Exercise 
Control  Module,  where  the  contents  are  read  and  a  Checkpoint, 
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Restart,  or  Shutdown  operation  is  carried  out.  Configuration 
data  are  passed  to  the  Configuration  Module,  which  updates 
its  tables  that  map  simulation  hosts  to  duty  position  roles 
and  call  signs  in  the  exercise. 

Packets  arriving  at  the  Radio  Interface  are  examined  to 
make  sure  that  they  are  from  a  SINCGARS  with  which  this 
simulator  is  associated  (if  SINCGARS  simulators  are  being 
used)  or  to  make  sure  that  they  are  f".om  a  radio  net  to  which 
this  simulation  is  connected  (if  SIN'.:  I\RS  simulators  are  not 
being  used).  Packets  that  pass  thii  ti.st  are  sent  to  the 
Dispatcher,  which  checks  what  type  of  ';ommand  and  control 
data  the  packet  contains.  The  Dispatcher  forwards  the  data 
appropriately:  overlay  data  to  the  Overlay  and  Concept-of- 

Operations  Module;  reports  and  routes  to  the  Report  and 
Navigation  Module;  vehicle  location  data  to  the  POSNAV 
Module,  and  vehicle  status  data  to  the  TOOE  Module.  Each 
module  then  processes  the  data  as  follows: 

•  The  Overlay  and  Concept  of  Operations  Module  places 
the  data  in  the  overlay  database  and  makes  it 
available  to  the  user  for  display.  If  the  user 
chooses  to  display  the  overlay,  the  Overlay  Module 
posts  the  objects  in  the  overlay  (point  icons,  unit 
icons,  control  measures,  etc.)  to  the  map. 

•  The  Report  and  Navigation  Module  processes  reports  and 
routes  in  a  similar  manner.  New  reports  are  stored  in 
the  report  database  and  an  entry  is  made  in  the 
"receive"  folder.  Displaying  the  contents  of  a  report 
causes  the  information  in  the  report  (such  as  target 
and  observer  locations)  to  be  posted  to  the  map  in  the 
form  of  report  icons . 

•  The  TOOE  Module  uses  the  vehicle  status  data  passed  to 
it  to  update  its  TOOE  hierarchy.  Any  TOOE  reports 
being  displayed  by  the  user  are  updated  from  the 
latest  data  in  the  hierarchy. 
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PROTOCOLS  USED  BY  THE  CVCC  SIMULATIONS 


The  CVCC  simulations  use  portions  of  the  following 
protocols  to  support  their  communications  and  interactions: 

•  simulation  protocol 

•  data  collection  protocol 

•  radio  simulation  protocol 

•  CVCC  protocol 

The  Simulation  protocol  section  describes  how  the 
simulation  protocol  is  used  to  support  interactions  between 
the  various  CVCC  simulations,  concentrating  on  the  individual 
systems  which  make  up  the  CVCC-equipped  tank  simulation 
(liADS,  1991d)  . 

The  Radio  simulation  protocol  section  briefly  describes 
the  portion  of  the  data  collection  protocol  which  is  used  to 
support  interactions  between  the  CITV  portion  of  the  enhanced 
Ml  tank  simulator  and  the  CCD  (LADS,  1991d) . 

The  CVCC  protocol  section  provides  a  brief  synopsis  of 
the  description  of  the  radio  simulation  protocol  appearing  in 
documentation  about  the  SIMNET  Simulation  of  Radio 
Communication  (Pope  et  al.,  1990). 

The  CVCC  protocol  was  created  specifically  to  support 
the  needs  of  the  CVCC  system.  It  is  described  in  full  in 
this  section. 


Simulation  Protocol 

The  CCD  and  SINCGARS  simulators  use  the  simulation 
protocol  to  obtain  information  about  the  vehicle  with  which 
they  are  associated.  As  mentioned  previously,  the  enhanced 
Ml  tank  simulator,  the  CCD  simulator,  and  the  SINCGARS  radio 
simulator  are  combined  to  produce  the  simulation  of  the  CVCC- 
equipped  tank.  The  enhanced  Ml  tank  simulator  works 
independently  of  the  other  two  simulators  and  is  unaware  of 
whether  they  are  connected  to  the  simulation  network.  The 
CCD  and  SINCGARS  simulators,  on  the  other  hand,  are 
associated  with  a  particular  enhanced  Ml  simulator  at 
runtime.  They  obtain  information  about  that  vehicle  by 
listening  to  the  Vehicle  Appearance  PDUs  that  it  broadcasts 
to  the  simulation  network. 
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The  CCD  simulator  extracts  location  and  state 
information  from  the  Vehicle  Appearance  PDUs  and  uses  it  to 
draw  its  own  vehicle  icon  with  the  correct  turret  orientation 
at  the  correct  location  on  the  tactical  map  display.  The  CCD 
also  communicates  status  information  extracted  from  the 
Vehicle  Appearance  PDUs  to  other  CCD  and  BnTOC  workstation 
simulators . 

The  SINCGARS  simulator  listens  for  Vehicle  Appearance 
PDUs  from  all  vehicles  that  have  radios.  It  uses  the 
location  infor-mation  in  those  PDUs  to  keep  track  of  the 
locations  of  the  vehicles  (and  thus  the  radios)  and  to  help 
determine  which  radios  can  communicate  with  one  another.  The 
SINCGARS  simulator  also  uses  the  state  information  in  Vehicle 
Appearance  PDUs  from  its  own  vehicle  to  help  determine  its 
own,  state.  For  example,  if  its  vehicle  is  destroyed,  the 
SINCGARS  knows  that  it  should  cease  transmitting  or 
receiving. 

The  BnTOC  workstations  do  not  use  the  simulation 
protocol . 


Data  Collection  Protocol 


The  data  collection  protocol  is  used  to  support  the 
interoperability  between  the  individual  systems  which 
together  make  up  the  CVCC  tank  simulation.  Specifically,  the 
enhanced  Ml  tank  simulator  uses  the  data  collection  protocol 
to  communicate  information  about  how  the  tank's  Laser  Range 
Finders  (LRF)  are  being  used.  The  CCD  uses  this  information 
when  filling  out  reports.  In  this  way,  the  CCD  supports 
entering  report  locations  using  the  CITV  LRF. 

The  particular  PDU  used  to  support  this  interoperability 
between  the  CCD  and  the  eiihanced  Ml  tank  simulator  is  the 
Laser  Range  Finder  PDU.  Laser  Range  Finder  PDUs  contain  the 
following  information: 

•  the  identity  of  the  vehicle  being  simulated 

•  the  identity  of  the  LRF  being  used  (grunner's  LRF  or 
CITV's  LRF) 

•  the  result  of  the  LRF  operation  (malfunction,  no 
locations  returned,  single  location  returned,  multiple 
locations  returned) 
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•  a  switch  to  identify  which  location  to  use  if  multiple 
locations  were  returned  (no  return,  first  return,  last 
return) 

•  the  location  returned  by  the  LRP  operation 


Radio  Simulation  Protocol 


The  SINCGARS  radio  simulations  use  the  radio  simulation 
protocol  to  report  noteworthy  events  and  statistics  to  each 
other,  as  well  as  to  simulate  transmitting  and  receiving 
voice  and  data  communications  (Pope  et  al.,  1990).  The  radio 
simulation  protocol  includes: 

•  Transmitter  PDUs 

•  Receiver  PDUs 

•  Signal  PDUs 

•  Intercom  PDUs 

•  Alert  Operator  PDUs 

A  simulated  radio  can  be  a  receiver,  a  transmitter,  or , 
as  in  the  case  of  the  SINCGARS  radio  simulator,  both. 
Transmitter  PDUs  and  Receiver  PDUs  communicate  state 
information  about  simulated  transmitters  and  receivers, 
respectively.  A  radio  simulation  issues  Transmitter  PDUs  and 
Receiver  PDUs  whenever  either  (a)  the  state  of  the 
transmitter  or  receiver  changes,  or  (b)  five  seconds  have 
elapsed  since  the  last  such  PDU  was  issued. 

The  content  of  a  radio  transmitter's  signal  over  a  brief 
period  of  time  is  described  by  a  Signal  PDU  issued  by  that 
transmitter's  simulator.  While  a  transmitter  is 
broadcasting,  its  simulator  repeatedly  issues  Signal  PDUs  to 
describe  successive  time  segments  of  the  transmitted  signal. 
These  PDUs  are  used  by  other  radio  simulators  to  decode  a 
received  signal . 

A  radio  simulator  may  be  privy  to  what  is  spoken  over  an 
intercom  inside  a  vehicle  as  well  as  what  is  spoken  for  radio 
transmission.  For  example,  the  SINCGARS  radio  simulators 
obtain  speech  signals  from  each  crew  member's  microphone, 
regardless  of  whether  those  crew  members  are  transmitting  on 
a  radio.  For  study  purposes,  it  may  be  desirable  to  record 
this  intercom  speech.  The  Intercom  PDU  is  used  to  report 
intercom  speech  via  the  simulation  network  so  that  it  can  be 
recorded  by  a  system  such  as  the  Data  Logger.  The  Intercom 
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PDU  contains  the  same  information  as  the  Signal  PDU,  except 
that  the  identity  of  the  vehicle  containing  the  speaker  is 
substituted  for  the  identity  of  the  radio. 

A  radio  simulator  can  emit  a  warning  or  alerting  tone 
through  a  simulated  radio  receiver's  speaker  or  headset.  For 
example,  the  real  SINCGARS  radio  is  supposed  to  do  this 
whenever  data  is  transmitted.  The  Alert  Operator  PDU 
supports  this  functional  capability. 


CVCC  Protocol 


The  CVCC  protocol  was  created  specifically  to  support 
the  communications  and  interactions  requirements  of  the  CVCC 
System  Architecture.  The  CVCC  protocol  breaks  down  into  four 
different  types  of  information  and  interactions. 

•  command  and  control  data 

•  vehicle  appearance  data 

•>  instrumentation  data 

•  execution  control  operations 

Each  of  these  categories  essentially  constitutes  a 
subprotocol  of  the  CVCC  protocol.  The  sections  which  follow 
described  each  of  thc.se  subprotocols  in  turn. 


Command  and  Control  Subprotocol 

The  primary  role  of  the  CVCC  protocol  in  the  CVCC  system 
architecture  is  to  support  the  communication  of  command  and 
control  information  between  the  various  systems  participating 
in  an  exercise.  The  command  and  control  subprotocol  supports 
this  role. 

The  command  and  control  subprotocol  can  be  divided  into 
two  layers.  The  inner  layer  defines  the  content  of  the 
command  and  control  information  that  can  be  communicated 
among  the  CVCC  simulations  (i.e.,  reports,  overlays,  vehicle 
location,  and  vehicle  status) ,  The  outer  layer  defines  the 
mechanism  by  which  this  information  is  communicated. 

The  command  and  control  subprotocol  is  used  by  the  BnTOC 
workstation,  CCD,  and  SAF. 
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Inner  Laver:  Conunand  and  Control  Information 


Command  and  control  information  can  be  divided  into  two 
basic  categories:  saveable  and  transient.  Saveable 
information  includes  reports,  routes,  and  overlays. 

Transient  information  includes  vehicle  location  and  vehicle 
status  information.  Saveable  information  generally  becomes 
part  of  a  command  and  control  database  (which  is  either 
private,  as  in  the  case  of  the  CCD  simulators,  or  shared,  as 
in  the  case  of  the  BnTOC  workstations) .  Transient 
information  is  generally  used  only  for  display  purposes.  It 
is  usually  updated  automatically  and  discarded  once  it  is  out 
of  date. 

Reports  —  Nine  different  Army  reports  are  supported  by 
the  command  and  control  protocol : 

«  Adjust  Fire  Report 

•  Call-For-Fire  Report 

•  Contact  Report 

•  Shell  Report 

•  SitRep  Report 

•  Spot  Report 

•  Intel  Report 

•  Free  Text  Report 

•  NBC  Report 

BnTOC  workstations  and  CCDs  can  send  and  receive  all 
CVCC  reports  listed  above  except  Free  Text  Reports— these  can 
be  prepared  and  sent,  and  received  and  forwarded  by  BnTOC 
workstations,  but  only  received  and  forwarded  by  CCDs.  In 
addition,  to  make  SAF  vehicles  behave  more  like  manned 
vehicles,  they  have  been  given  the  ability  to  send  Contact, 
Shell,  and  Spot  reports.  In  the  CVCC  MWTB  environment,  this 
means  they  have  command  and  control  capabilities  similar  to 
those  of  the  real  CVCC-equipped  tank. 

The  Adjust  Fire  Report  includes: 

•  Suppress  versus  Fire-for-Ef feet  indicator 

•  End-of-Mission  indicator 
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•  identifier  of  the  Call-For-Pire  Report  with  which  the 
Adjust  Fire  Report  is  associated 

<*  either  an  absolute  target  location  or  a  specification 
of  the  number  of  meters  to  add/subtract  and  shift 
left/right 

The  Call-For-Fire  (CFF)  Report  includes: 

•  location  of  the  observer 

•  target  location  and  target  type  (the  target  can  be  a 
tank,  anti-tank  guided  missile,  helicopter,  fixed-wing 
aircraft,  artillery,  personnel  carrier,  truck,  or 
troops ) 

•  number  of  targets  sighted 

•  concentration  number  (if  one  exists)  corresponding  to 
the  specified  location 

The  Contact  Report  includes  two  target/location  entries. 

The  Shell  Report  includes: 

•  location  of  the  shelling 

•  number  of  shells  involved 

•  time  when  the  shelling  occurred  (as  opposed  to  when 
the  report  was  created) 

The  SitRep  Report  includes: 

•  endpoints  of  the  front  line  of  troops  (FLOT) 

•  enemy's  activity  level  (low,  medium,  or  high) 

•  enemy's  activity  type  (air  attack,  ground  attack, 
firing,  defending,  delaying,  or  reconnaissance) 

•  commander's  intention  (no  change,  attacking, 
reconnaissance,  defending,  delaying,  or  withdrawing) 

•  indications  about  critical  shortages  of  aunmunition, 
equipment,  fuel,  and  personnel 

•  time  to  which  the  situation  report  refers  (as  opposed 
to  the  time  when  it  was  created) 
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The  Soot  Report  includes: 


•  location  where  the  activity  was  observed 

•  what  was  seen  (tank,  anti-tank  guided  missile, 
helicopter,  fixed-wing  aircraft,  artillery,  personnel 
carrier,  truck,  or  troops) 

•  number  of  units  seen,  damaged,  and  destroyed 

•  enemy ' s  heading 

•  enemy's  activity  and  own  actions  (air  attack,  ground 
attack,  firing  , defending,  delaying,  reconnaissance) 

•  time  when  the  observation  occurred  (as  opposed  to  the 
time  when  the  spot  report  was  created) 

The  Intel  Report  includes  information  about  enemy  units, 
friendly  units,  and  obstacles. 

The  information  about  enemy  and  friendly  units  includes: 

•  unit  location 

•  for  enemy  forces:  type  of  units  involved  (tank,  anti¬ 
tank  guided  missile,  helicopter,  fixed-wing  aircraft, 
artillery,  personnel  carrier,  truck,  troops) 

•  for  friendly  forces:  type  of  units  involved 
(artillery,  command  and  control,  mechanized  infantry, 
mortar,  scout,  support,  tank) 

•  niomber  of  vehicles  involved 

•  activity  (air  attack,  ground  attack,  firing, 
defending,  delaying,  reconnaissance) 

The  obstacle  information  includes  the  location  type  of 
the  obstacle: 

•  abati 

•  blown  bridge 

•  minefield 

•  tank  ditch 

The  Intel  report  also  includes  the  time  to  which  the 
report  refers  (as  opposed  to  the  time  at  which  it  was 
created) . 
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The 


includes  512  characters  of  text . 


The  NBC  Report  includes: 

•  the  location  of  the  observer 

•  the  location  of  the  attack 

•  the  burst  type  (air,  surface,  unknown) 

•  the  attack  type  (nuclear,  biological,  chemical) 

•  the  f lash-to-bang  time 

•  the  number  of  shells  observed 

•  in  the  case  of  a  nuclear  attack,  the  size  of  the 
crater  and  the  height  and  width  of  the  nuclear  cloud 

Routes  —  are  an  ordered  list  of  waypoints.  Only  CCD 
simulators  send  and  receive  routes. 

Overlays  -  The  CVCC  protocol  supports  the  communication 
of  graphical  overlays  between  applications,  specifically 
overlays  created  using  the  symbols  and  standards  defined  in 
the  Army  Field  Manual  FM  101-5-1  (U.S.  Army,  1985)  .  Whether 
a  given  application  can  actually  display  these  overlays 
depends  on  which  library  is  used  for  drawing  symbols. 

The  BnTOC  workstation  and  CCD  use  the  overlays  portion 
of  the  command  and  control  subprotocol  to  communicate 
graphical  overlays,  including  OpOrds,  FRAGOs,  SitEsts,  and 
Fire  Support  overlays .  The  CVCC  command  and  control 
subprotocol  is  not  capable  of  communicating  Concept-  of- 
Operations  overlays . 

In  the  CVCC  protocol,  graphical  overlays  are  composed  of 
three  fundamental  building  blocks; 

•  point  symbols 

•  poly-line  objects 

•  text  objects 

Point  symbols  occupy  a  single  point  on  the  terrain. 

There  are  three  basic  categories  of  point  symbols: 

•  vehicle  icons  (e.g.,  tanks,  mechanized  infantry 
vehicles,  scout  vehicles,  etc.) 
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•  unit:  icons  aimor  units,  infantry  units,  ate.) 

•  point  icons  (tt.g.,  waypoints,  target  reference  points, 
etc ,  ) 

Point  syinbola  include  information  identifying  the  type 
of  point  symbol  (tan'  .  \rmo.f  unit,  waypoint,  etc.)  and  the 
location  of  t)ie  object  Point  symbols  for  unit  icons  have  a 
unit  size  identifier  (section,  platoon,  company,  battalion, 
brigade,  etc.).  Any  point  syn\bol  can  have  up  to  eight  tags 
associated  with  it.  Each  tag  consists  of  a  character  string 
and  information  about  \'here  it  appears  relative  to  the  core 
symbol  (above,  below,  three  positions  on  the  left,  and  three 
positions  on  the  right) .  Finally,  point  symbols  have 
attributes  that  identify  thoi.r  orientation  (friendly  or 
enemy)  and  their  status  (proposed  or  confirmed) . 

Poly-liKip  objects  occupy  two  or  more  points  on  the 
terrain.  They  can  be  used  with  text  objects  to  create 
control  measures.  There  are  three  categories  of  poly-line 
objects : 


•  lines  (boundary  lines,  phase  lines,  etc.) 

•  arrows  (direction  of  advance,  axis  of  advance,  etc.) 

•  polygons  (restricted  fire  areas,  minefields,  etc.) 

Poly-i.ine  objects  include  information  identifying  the 
following : 

•  type  of  poly-line  object  (boundary  line,  direction  of 
advance,  restricted  fire  area,  etc.  ) 

»  location  (specified  by  a  list  of  vertices) 

•  how  the  object  should  appear  when  drawn,  including: 

*  init  size  identifier  (section,  platoon,  company, 
etc .  ) 

*  location  of  the  rnit  size  indicator  (i.e.,  the 
specific  vertex) 

*  whether  the  poly-line  is  splined  (i.e.,  drawn  with 
smoothing) 

•  orientation  (friendly  or  enemy) 

•  status  (proposed  or  confirmed) 
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can  be  used  to  represent  comments  on  the 
overlay  or  to  create  text  labels  for  poly- line  objects.  They 
include : 


•  type  of  text  object  (comments  or  poly- line  labels) 

•  location  of  th  v^ext  on  the  overlay  in  Universal 

Transverse  Merc  (UTM)  coordinates 

•  offset  from  the  Ic  ior-  (in  screen  coordinates) 

•  character  string  o  .e  ^ext  itself 

Vehicle  location  and  sl^aCus  -  The  CCD  simulations 
receive  location  and  status  information  about  their  vehicles 
from  the  simulation  and  data  collection  protocols, 
respectively.  They  share  this  information  with  other  CCD 
simulations  using  the  Vehicle  Status  packet?  of  the  CVCC 
command  and  control  subprotocol.  The  CCD  simulations  also 
communicate  the  current  Task  Organization  characteristics  of 
the  vehicle  (and,  by  extension,  the  tank  commander).  To  make 
the  distinction  between  manned  and  unmanned  (SAP)  CVCC 
simulations  invisible  to  the  user  in  the  CVCC  experime  s, 
the  SAP  vehicles  have  been  given  the  capability  of  sendi.ig 
this  vehicle  status  information  via  Vehicle  Status  and  Group 
Status  packets. 

The  Vehicle  Status  packet  includes  information  about  the 
following : 

•  location  of  the  vehicle.  This  information  is  used  by 
the  BnTOC  workstations  and  CCD  simulators  to  draw 
vehicle  and  unit  icons  on  the  tactical  map. 

•  status  information  used  by  the  BnTOC  workstations  and 
CCD  simulators  to  present  the  Operational 
Effectiveness  of  the  tank  battalion  and  its  component 
units : 

*  ammunition  status  -  including  the  types  of 
ammunition  and  the  number  of  rounds  of  each  type 
avad  Tflble 

*  equipment  status  -  whether  its  fire  and  mobility 
subsystems  are  functioning 

*  fuel  status  -  number  of  gallons  of  fuel  available 

*  personnel  status  (okay,  wounded,  killed)  of  each  of 
the  crew  memt)ers  (commander,  gunner,  loader, 
driver) ,  (Note :  In  the  current  simulation 
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personriol  status  is  not  tracked.  Rather,  it  is 
always  assumed  to  be  okav. ) 

•  current  task  organization  of  the  vehicle,  including; 

*  duty  position  of  the  tank  commander  in  the 
battalion 

*  duty  position  of  the  person  to  whom  the  tank 
commander  is  currently  reporting 

*  whether  the  tank  commander  is  currently  leading  a 
unit 

*  unit  currently  led  by  the  tank  commander 

(The  information  about  task  organization  is  included 
in  the  Vehicle  Status  packets  to  support  two 
functional  capabilities:  the  display  of  the 
operational  ef fectiveneas  of  vehicles  and  units  within 
the  combat  organization,  and  dynamic  changes  to  the 
task  organization  of  units  within  the  overall  combat 
organization.  The  latter  capability  is  not  currently 
available  in  either  the  BnTOC  workstations  or  the  CCD 
simulators . ) 

The  Group  Status  packet  simply  provides  a  way  of 
grouping  Vehicle  Status  packets  for  more  efficient 
communications  over  the  simulation  network. 


Outer  Laver;  Data  Communications 

The  outer  layer  of  the  CVCC  command  and  control 
subprotocol  allows  the  BnTOC  workstation,  CCD,  and  SAP 
simulations  to  share  the  command  and  control  information 
described  above.  This  layer  consists  of  the  following  types 
of  PDUs: 


•  Broadcast  PDU 

•  Transmit  Request  PDU 

•  Transmit  Response  PDU 

•  Receive  PDU 

•  Point-To  Point  PDU 


The  Broadcast  PDU  is  used  by  the  CVCC  applications  to 
share  command  and  control  information  without  using  the  data 
communications  services  of  the  SINCGARS  simulation.  The  SAP 
simulators  always  use  Broadcast  PDUs  to  transmit  conunand  and 
control  information.  The 
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Response  PDU,  and  are  used  by  the  CVCC 

applications  to  share  command  and  control  infoi'mation  using 
the  data  communications  services  of  the  SINCGARS  radio 
simulation.  The  Point  To  Point  PDU  is  used  by  BnTOC 
workstations  to  send  command  and  control  infox^mation  directly 
to  one  another . 

The  command  and  control  information  in  the  Broadcast 
PDUs  transmitted  by  the  SAF  simulators  to  the  other  CVCC 
applications  on  the  simulation  network  includes  spot  reports, 
contact  reports,  CFF  reports,  and  vehicle  status  packets  (see 
the  section  on  the  inner  layer;  command  and  control 
information) .  SAF  simulators  only  send  command  and  control 
data  to  the  simulation  network.  They  never  receive  it. 

The  BnTOC  workstations  and  CVCC  simulators  can  operate 
either  utilizing  SINCGARS  radios  for  data  communications  or 
by  placing  the  data  packets  directly  on  the  simulation 
network.  (See  the  section  on  data  communications  without 
SINCGARS. ) 

The  BnTOC  workstations  do  not  use  the  SINCGARS  radio 
simulators  to  send  command  and  control  to  each  other,  since 
they  are  co- located  within  the  same  TOC.  When  BnTOC 
workstations  send  command  and  control  information  directly  to 
one  another,  they  use  the  Point  To  Point  PDU. 

The  next  three  sections  summarize  the  PDUs  that  belong 
to  the  data  communications  layer  of  the  CVCC  command  and 
control  subprotocol. 


Data  coiMunications 

Broadcast  PDUs  are  used  by  the  CVCC  applications  to 
communicate  command  and  control  data  directly  without  using 
the  SINCGARS  radio  simulation.  Broadcast  PDUs  also  include 
the  identity  of  the  sender  and  the  command  network  being  used 
to  carry  the  message  (battalion  command  net.  Company  A 
command  net,  Platoon  A/1  command  net,  etc.) .  This  mode  is 
useful  when  running  the  CVCC  simulator  on  a  standalone 
network  that  docs  not  have  SINCGARS  simulators. 


Data  CQimnutiicAtiQna  .with  ..SINCGARS . 

Transmit  Request  PDUs,  Transmit  Response  PDUs,  and 
Recexve  PDUs  define  the  interface  made  available  by  the 
SINCGARS  radio  simulation  to  applications  that  use  its  RIU 
data  communications  capabilities.  The  simulation  of  the  RIUs 
in  the  SINCGARS  radios  provides  data  comm\mi cat ions  in 
various  modes,  including  reliable  and  unreliable  point- to- 
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point,  reliable  and  unreliable  multicast,  and  unreliable 
broadcast  transmissions.  Although  all  of  these  modes  are 
supported  in  the  interface  as  defined  by  the  Transmit 
Request,  Transmit  Response,  and  Receive  PDUs,  only  the 
unreliable  broadcast  mode  is  used  by  CCD  and  BnTOC. 

The  Transmit  Request  PDU  is  used  by  an  application  to 
request  communication  of  a  message  by  an  RIU.  It  includes 
the  following  information: 

•  identity  of  the  radio  transmitter 

•  command  network  carrying  the  message  (battalion 
command  net.  Company  A  command  net,  Platoon  A/1 
command  net,  etc.) 

•  the  message  itself 

•  Information  used  to  tell  the  RIU  what  mode  to  use  for 
the  transmission: 

*  serial  number  identifying  the  request 

*  an  indication  of  whether  the  transmission  is 
intended  for  all  receivers  (broadcast)  or  a  subset 
(point-to-point  or  multicast) 

*  an  indication  of  whether  the  transmission  is  to  be 
reliable  (needs  to  be  acknowledged)  or  unreliable 
(does  not  need  to  be  acknowledged) 

*  priority  of  the  conununication 

*  list  of  recipients 

The  Transmit  Response  PDU  is  used  by  the  RIU  in  the 
radio  simulator  to  report  back  to  the  requesting 
application  the  results  of  trying  to  communicate  a 
message.  It  includes: 

•  identity  of  the  radio  transmitter 

•  command  network  carrying  the  message  (battalion 
coiTunand  net.  Company  A  command  net.  Platoon  A/1 
command  net ,  etc . ) 

•  serial  number  of  the  original  transmit  request  PDU 

•  list  of  the  failing  receivers 
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The  Receive  PDU  is  used  by  the  RIU  in  the  radio 
simulator  to  convey  a  received  message  to  an 
application  (i.e.,  CCD).  It  includes: 

•  identity  of  the  radio  transmitter 

•  command  network  carrying  the  message  (battalion 
command  net,  Company  A  command  net,  Platoon  A/1 
command  net,  etc.) 

•  the  message  itself 

Pai;a  ,,coiiimunica.tiQQg.,,,  batwgsn-llifi,,  ,BnTOC..AtfQr.lis.tal;iQiia  ■ 

The  BnTOC  workstations  conununicate  command  and  control 
information  between  themselves  using  the  Point  To  Point  PDU. 
The  Point  To  Point  PDU  allows  BnTOCs  to  send  information  to 
any  subset  of  the  supported  BnTOC  workstations.  This 
separate  mechanism  is  supported  by  BnTOC  work.stations  because 
co-located  TOC  workstations  in  the  field  would  be  unlikely  to 
be  networked  together  via  radios.  Instead,  workstations 
would  be  likely  to  be  connected  directly  to  each  other  using 
an  local  network,  enabling  them  to  communicate  directly  with 
each  other. 

The  Point  To  Point  PDU  contains  a  list  of  BnTOC 
workstation  recipients  (e.g,  BnCO,  BnS2)  and  the  message 
being  sent.  The  message  contains  an  identification  of  the 
sender,  an  indication  of  the  type  of  information  being  sent 
and  the  data  itself. 


The  vehicle  appearance  subprotocol  of  the  CVCC  protocol 
supports  the  special  requirements  of  the  enimnced  Ml  tanks  to 
describe  the  orientation  of  the  CITV.  This  information  is 
used  by  the  CCD  to  properly  depict  the  icon  for  its  own 
vehicle  on  the  tactical  map. 

The  vehicle  appearance  subprotocol  consists  of  a  single 
PDU,  the  CITV  Orientation  PDU,  which  contains  the  following 
information: 

•  the  identity  of  the  vehicle  being  simulated 

•  the  angle  describing  the  azimuth  of  the  CITV 

•  the  angle  describing  the  ele''''ation  of  the  CITV 
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Instrumentation  Subprotocol 


The  CVCC  instrumentation  subprotocol  was  designed 
specifically  to  support  the  data  collection  needs  of  the  CVCC 
experiments  at  the  MWTB.  It  allows  the  BnTOC  workstations, 
CCD  simulations,  and  the  CITV  simulation  to  communicate 
information  to  the  simulation  network  about  how  they  are 
being  used  by  the  soldiers  participating  in  the  experiments. 
This  information  can  be  saved  by  a  program  such  as  the  data 
logger  and  analyzed  using  data  analysis  software.  Thus,  the 
CVCC  instrumentation  subprotocol  provides  the  means  to 
measure  the  effectiveness  of  the  prototype  weapons  and  the 
command  and  control  systems  that  are  the  focus  of  the 
experiment.  The  information  in  the  instrumentation 
subprotocol  is  critical  to  the  entire  ARI  effort. 

The  CVCC  Instrumentation  subprotocol  includes  the 
following  PDUs: 

•  CITV  Instrumentation  PDU 

•  CCD  Instrumentation  PDU 

•  BnTOC  Instrumentation  PDU 

Each  of  these  PDUs  communicates  information  to  the 
simulation  network  about  how  the  corresponding  simulation  is 
being  used. 

The  CITV  Instrumentation  PDUs  are  sent  to  the  simulation 
network  periodically  and  contain  the  following  information: 

•  identity  of  the  vehicle  to  which  the  CITV  belongs 

•  mode  of  the  CITV  (off,  cooling,  search  mode,  auto  scan 
mode,  gunner's  line-of -sight  mode,  GPS  mode,  standby) 

•  CITV  magnification  (3x,  lOx) 

•  CITV  polarity  (white  hot,  black  hot) 

•  state  information,  including  vrhether  the  designator  is 
pushed,  whether  the  commander's  stack  button  is 
pushed,  and  whether  the  gunner's  stack  button  is 
pushed  (when  the  target  stacking  is  enabled) . 

•  left  and  right  sector  limits  and  the  .scan  rate,  if  the 
CITV  is  in  auto  scan  n.ode 

The  CCD  Instrumentation  PDUs  report  information  about. 
the  generation  of  Army  reports,  actions  taken  on  messages, 
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the  current  state  of  the  tactical  map,  and  cumulative  action 
and  object  counts: 

•  generation  of  Army  reports.  These  PDUs  are  sent  by 
the  CCD  simulators  when  the  reports  are  generated  and 
include  the  following  information: 

*  unique  identifier  for  the  report 

*  amount  of  time  that  the  user  was  actively  engaged 
in  creating  the  report 

*  action  taken  on  the  report  (cancel,  send) 

*  type  of  report  (Adjust  Fire,  CFF,  Contact,  Shell, 
SitRep,  Spot,  Intelligence,  Free  Text,  NBC) 

•  actions  taken  on  messages.  These  PDUs  are  sent  by  the 
CCD  simulators  when  the  action  occurs  and  inclvide  the 
following  information: 

*  unique  identifier  for  the  message 

*  call  sign  of  the  originator 

*  call  sign  of  the  sender 

*  message  type  (report,  route,  overlay) 

*  type  of  report  (if  the  message  is  an  Army  report) : 
Adjust  Fire,  CFF,  Contact,  Shell,  SitRep,  Spot, 
Intelligence,  Free  Text,  NBC 

*  action  performed  on  the  message:  relayed,  relayed 
up,  relayed  down,  saved,  deleted,  viewed,  received, 
removed  from  receive  queue  by  user,  aged  from 
receive  queue  by  system,  posted  to  the  tactical 
map,  unposted  from  the  tactical  map,  route  was  made 
the  active  route 

*  method  by  which  the  user  selected  the  message  for 
viewing  (if  the  action  performed  was  to  view  the 
message) :  from  the  receive  queue,  from  an  "old 
message"  file,  or  by  touching  a  report  icon  on  the 
tactical  map 

•  current  state  of  the  tactical  map.  These  PDUs  are 
sent  periodically  by  the  CCD  simulators  and  include 
the  following  information: 

*  map  scale  (1:25K,  1:50K,  1:125K,  1;250K) 
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*  map  features  currently  displayed  (grid  lines, 
rivers,  roads,  vegetation,  buildings,  contour 
lines) 

*  coordinates  of  the  center  of  the  map 

*  map  scroll  mode  (jump  mode,  follow  mode,  move  mode) 

•  cumulative  action  and  object  counts.  These  PDUs  are 
sent  periodically  and  include  the  following 
information: 

*  type  of  the  object  or  action  being  counted  (high- 
priority  messages  in  the  receive  queue,  low- 
priority  messages  in  the  receive  queue,  thumb 
designator  selects,  touchscreen  selects,  locations 
specified  by  touching  the  tactical  map,  locations 
specified  by  using  the  Laser  Range  Finder) 

*  map  features  currently  displayed  (grid  lines, 
rivers,  roads,  vegetation,  buildings,  contour 
lines) 

*  coordinates  of  the  center  of  the  map 

*  map  scroll  mode  (jump  mode,  follow  mode,  move  mode) 

The  BnTOC  Instrumentation  PDUs  report  information  about 
report  events,  folder  events,  overlay  events,  the  current 
state  of  the  overlay  staclc,  and  the  current  state  of  the 
tactical  map: 

•  report  events .  These  PDUs  are  sent  by  the  BnTOC 
WorJcstations  when  the  event  occurs  and  include  the 
following  information; 

*  unique  identifier  for  the  report 

*  call  sign  of  the  originator 

*  action  taJcen  on  the  report  (report  arrives  ,  *  report 
is  viewed,  report  is  copied,  report  is  linked  to  an 
overlay,  report  is  relayed,  report  is  aggregated, 
report  is  filtered,  report  is  deleted) 

-  For  the  report  arrives  event,  this  information 
includes  the  call  sign  of  the  sender. 

-■  For  the  report  is  viewed  event,  this  information 
includes  an  identifier  of  the  folder  from  which 
it  is  being  viewed.  This  identifier  includes 
the  role  of  the  BnTOC  Workstation  to  which  the 
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folder  belongs  (BnCO/XO,  BnS3,  BnS2,  BnFSO)  and 
the  name  of  the  folder. 


-  For  the  report  is  copied  event,  this  information 
includes  the  identifier  of  the  source  and 
destination  folders  of  the  report. 

-  For  the  report  is  linked  event,  this  information 
includes  the  identifier  of  the  overlay  to  which 
it  is  being  linked.  This  identifier  includes 
the  role  of  the  BnTOC  Workstation  to  which  the 
overlay  belongs  (BnCO/XO,  BnS3 ,  BnS2 ,  BnFSO)  and 
the  name  of  the  overlay. 

-  For  the  report  is  relaved  event,  this 
information  includes  the  identifier  of  the 
folder  containing  the  report  and  a  list  of 
recipients  for  the  report  ( BnCommandNet ,  BnSl, 
BnS2,  BnS3,  BnS4,  BnFSO,  BnXO,  BnCO, 

BnSitDisplay,  BdeCommandNet ) . 

-  For  the  report  is  aggregated  event,  this 
information  includes  a  list  of  the  reports  that 
form  part  of  the  aggregate  report. 

-  For  the  report  is  filtered  event,  there  is  no 
additional  information. 

-  For  the  report  is  deleted  event,  this 
information  includes  the  identifier  of  the 
folder  from  which  the  message  is  being  deleted. 

*  information  about  the  event  (depends  on  the  type  of 
the  event) 

•  folder  events.  These  PDUs  are  sent  by  the  BnTOC 
Workstations  when  the  event  occurs  and  include  the 
following  information: 

*  type  of  folder  event  (folder  is  created,  folder  is 
deleted,  folder  is  viewed,  folder  is  closed) 

identifier  of  the  folder  on  which  the  event  is 
taking  place.  This  identifier  includes  the  role  of 
the  BnTOC  Workstation  role  to  which  the  folder 
belongs  (BnCO/XO,  BnS3,  EnS2,  BnFSO)  and  the  name 
of  the  folder. 
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*  overlay  events .  These  PDUs  are  sent  by  the  BnTOC 
Workstations  when  the  event  occurs  and  include  the 
following  information: 

*  type  of  event  (post,  unpost,  move  to  top,  move  to 
bottom,  circle  up,  circle  down,  create,  edit,  send, 
delete,  save,  save  as  rename,  copy) 

*  identifier  of  the  overlay  on  which  the  event  is 
taking  place.  This  identifier  includes  the  role  of 
the  BnTOC  Workstation  to  which  the  overlay  belongs 
(BnCO/XO,  BnS3 ,  BnS2,  BnFSO)  and  the  name  of  the 
overlay. 

*  for  a  create  event,  an  indication  of  what  type  of 
overlay  was  created  (normal,  concept  of  operations) 

*  for  a  save  as.  rename ,  or  copy  event,  an  the 
identifier  of  the  source  and  destination  overlays 

•  current  state  of  the  overlay  stack.  These  PDUs  are 
sent  periodically  by  the  BnTOC  Workstations  and 
include  the  following  information: 

*  a  list  of  identifiers  of  the  overlays  currently 
posted  to  the  map.  Each  identifier  includes  the 
role  of  the  BnTOC  Workstation  to  which  the  overlay 
belongs  (BnCO/XO,  rnS3,  ^nS2,  BnFSO)  and  the  name 
of  the  overlay. 

•  current  state  of  the  '•'tl'.al  map.  These  PDUs  are 

sent  periodica'  •  the  Bn'i’OC  Workstations  and 
include  the  fc  ag  inforiiiation: 

*  map  scale-  (1:25K,  1:50K,  1:125K,  1:250K) 

*  map  features  currently  displayed  (grid  lines, 
rivers,  roads,  vegetation,  buildings,  contour 
lines) 

*  coordinates  of  the  center  of  the  map 

*  map  scroll  mode  (scroll  bars,  auto  scroll,  drag 
scroll,  home,  go  to,  resize) 
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E:tgcutiQn  Cgntizg.I.  Subpr.<?t<2.gQl 


The  CVCC  execution  control  subprotocol,  like  the  CVCC 
instrumentation  subprotocol,  has  an  administrative  function 
in  the  CVCC  experiments  at  the  MWTB.  It  includes  the 
Execution  control  PDU,  which  provides  support  for  two  types 
of  exercise  control  capabilities: 

•  checkpoint  operations 

•  shutdown  of  all  CVCC  applications 

Checkpoint  support  -  Checkpointing  is  the  process  by 
which  a  CVCC  application  saves  its  current  state  or  context. 
This  includes  all  information  critical  to  the  curi'ent 
operating  context  of  the  application.  Receiving  a  command  to 
create  a  checkpoint  causes  an  application  to  save  its  current 
state.  Receiving  a  command  to  recover  a  checkpoint  causes  an 
application  to  replace  its  current  execution  state  with  the 
saved  execution  state  specified  in  the  command.  Receiving  a 
command  to  delete  a  checkpoint  causes  an  application  to 
delete  the  specified  checkpoint,  which  presumably  had  been 
previously  saved. 

The  checkpoint  support  provided  by  the  CVCC  execution 
control  subprotocol  provides  for  three  checkpointing 
operations;  creating  a  checkpoint,  deleting  a  checkpoint,  and 
recovering  a  checkpoint.  Each  operation  includes  a  text 
string  identifying  the  checkpoint.  The  CCD  and  the  BnTOC 
workstations  currently  participate  in  the  checkpoint  facility 
supported  by  the  CVCC  execution  control  subprotocol .  The  SAF 
has  to  be  checkpointed  manually  and  does  not  participate  in 
the  current  checkpoint  facility. 

Shutdown  support  —  The  CVCC  execution  control 
subprotocol  provides  support  for  a  shutdown  command.  Upon 
receipt  of  the  shutdown  command  from  the  control  application, 
all  participating  applications  terminate. 
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CONCLUSION 


The  CVCC  system  represents  a  major  accomplishment  in 
terms  of  demonstrating  the  feasibility  and  utility  of 
integrating  a  computer-based  command  and  control  system  into 
the  battlefield.  The  system  has  garnered  much  at  ntion  for 
its  functionality  and  its  ease  of  use.  In  additi  ,  the 
architecture  of  the  CVCC  software  provides  a  flexible  system 
which  allowed  the  functional  capabilities  of  the  simulators 
and  the  BnTOC  to  be  varied  utilizing  software  switches. 

The  system  as  it  stands  represents  the  concerted  efforts 
of  the  customer,  military  experts,  and  the  contractor  to 
build  the  best  possible  system  through  an  iterative  process 
of  specification,  design,  implementation,  and  testing.  The 
lessons  learned  in  each  cycle  served  to  focus  the  effort  to 
refine  and  extend  the  system  in  the  next  phase.  The  result 
has  been  a  base  of  software  which  is  at  once  highly  useful, 
usable,  and  configurable,  and  at  the  same  time  highly 
modular.  Thus,  it  provides  an  excellent  base  to  be  built 
upon  for  future  experiment. 

A  few  words  of  warning  to  those  who  would  do  so.  First, 
the  CVCC  system  is  by  no  means  a  finished  product.  It 
represents  the  best  good- faith  efforts  of  the  customer  and 
contractor  to  balance  the  need  to  provide  the  highest  level 
of  functional  capabilities  with  the  sometimes  conflicting 
need  for  robust,  error-free  software.  As  one  might  expect, 
time  and  money  ran  out  long  before  the  ideas.  A  number  of 
program  errors  were  discovered  in  the  software  which  were  not 
corrected.  (The  list  of  open  program  errors  is  included  at 
the  end  of  this  report  as  Appendix  E.)  As  a  result,  a  number 
of  capabilities  were  specified  and  designed  but  never 
implemented . 

Among  these  functional  capabilities  are  extensions  to  the 
Fire  Support  Module  capabilities,  the  addition  of  the  ability 
to  edit  task  organization  hierarchies  to  the  Task  Organization 
Module,  the  addition  of  execution  matrix  editing  and  terrain 
reasoning  to  the  Planning  Workstation,  and  the  addition  of  a 
Personnel  Module.  Other  ideas  have  included  extending  the  CVCC 
command  and  control  protocol  to  support  more  of  the  command  and 
control  requirements  of  the  Armed  Forces  into  a  single  .system, 
integrating  artillery  elements,  close  air  support  elements,  and 
combat  service  support  elements.  Additionally,  proposals  have 
been  made  for  integrating  the  BnTOC  workstations  and  the  SAF 
system  to  provide  a  system  for  training  BnTOC  officers  or  for 
seamlessly  commanding  units  in  an  environment  of  manned  and 
unmanned  vehicles . 
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In  suimmary,  the  CVCC  system  provides  an  excellent 
platform  to  build  upon  to  test  out  command  and  control 
concepts  for  future  systems.  Potential  users  should  be  aware 
that  some  problems  still  exist  in  the  software  which  may  have 
to  be  corrected  if  this  is  to  be  accomplished.  In  addition, 
one  of  the  great  accomplishments  of  the  CVCC  experiment  is 
the  ease  of  use  of  the  Man-Machine  interface.  This  was 
accomplished  as  a  result  of  considerable  time  and  effort. 
Potential  users  of  this  software  should  not  underestimate  the 
amount  of  effort  required  when  making  plans  to  enhance  the 
functional  capabilities  of  the  system. 
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APPENDIX  A 


ACRONYMS  AND  TERMS 


A/D  Analog  to  Digital 

ADDA  board 

Analog  to  Digital /Digital  to  Analog  Converter 

ADST  Advemced  Distributed  Simulation  Technology 

ALOC  The  administration  and  logistics  console  of  the 

MCC,  providing  a  GUI  for  repair  and  recovery, 
resupply  (fuel  and  eimmunition)  . 

APCHQ  Adaptive  Pulse  Code  with  Hybrid  Quantization 
compression  algorithm 

APIU  Adaptable  Programmable  Interface  Unit 

ARI  Army  Research  Institute 

BLUFOR  Friendly  force  vehicles 

BnTOC  Battalion  Tactical  Operations  Center 

C3  Command,  Control,  and  Communications 

CAS  The  close  air  support  console  of  the  MCC. 

CCD  Command  and  Control  Display.  A  prototype  of  a 

vehicle-based  Command  and  Control  system  which 
allows  the  tjuik  commander  to  send,  receive,  and 
manipulate  various  types  of  command  and  control 
data. 


CECOM 

Communications  Electronics  Command 

CES 

The  combat  engineering  support 

console  of  the  MCC. 

CFF 

Call-For-Fire 

CIG 

Computer  Image  Generator 

CITV 

Commander ' s  Independent  Thermal 

Viewer 

CO 

Commanding  Officer 
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coo 

CPU 

CRT 

CSS 

CVCC 

CVSD 

D/A 

DARPA 

DED 

DI 

DMA 

ECCM 

PLOT 

FSE 

FSO 

FWA 

GUI 

I/O 

IFF 

LADS 

LAN 


Concept -of -operations  overlay;  consist  strictly  of 
unit  icons  belonging  to  an  organic  task 
organization  hierarchy  such  as  an  armor  battalion. 

Central  Processing  Unit, 

Cathode  ray  tube  monitor 

Combat  Service  Support 

Combat  Vehicle  Command  and  Control 

Continuously  Variable  Slope  Delta  compression 
algorithm 

Digital  to  Analog 

Defense  Advanced  Research  Projects  Agency 

Dynamic  Element  Database 

Dismounted  Infantry 

Defense  Mapping  Agency 

Electronic  Counter-Counter  Measure 

Front  line  of  troops 

The  fire  support  element  console  of  the  MCC 

Fire  Support  Officer  Workstation  used  by  the  fire 
support  officer  assigned  to  the  battalion  TOC  from 
the  divisional  artillery  battalion. 

Fixed  Wing  Aircraft 

Graphical  User  Interface 

Input/Output 

Identification  Friend  or  Poe  System 
Loral  Advanced  Distributed  Simulation 
Local  area  network 
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MANPRINT 


Manpower  and  Personnel  Integration 


MCC  Management,  Command  and  Control.  A  set  of  consoles 

that  allow  exercise  control  and  provide  logistics 
and  combat  support.  The  MCC  stations  include  a 
master  console  for  exercise  control  called  the 
simulation  control  console  (SCC)  and  five  other 
consoles  that  provide  GUIs  for  repair  and  recovery, 
resupply  (fuel  2md  ammunition)  called  the 
administration  and  logistics  console  (ALOC) ,  combat 
engineering  support  (CES) ,  fire  support  element 
(FSE) ,  and  close  air  support  (CAS)  roles  during  an 
exercise.  Each  of  these  consoles  communicates  with 
the  MCC  backend  (SAF  Station)  which,  like  the  SAF 
Sim,  is  responsible  for  controlling  the  unmanned 
vehicles . 

MCS  Maneuver  Control  System 

MWTB  Mounted  Warfare  Test  Bed 

OE  Operational  effectiveness 

OSP  Open  Software  Foundation 

Out-the-window 

The  view  from  a  manned  simulator 
Protocol  Data  Units 
Position  Navigation 

Radio  Interface  Unit.  Interface  which  negotiates 
between  voice  and  data  transmissions. 

Rotary  Wing  Aircraft 

Intelligence  Officer 

Operations  Officer 

Semi -Automated  Forces.  Memy  unmanned  vehicles  in 
the  virtual  environment  under  the  control  of  a 
single  operator.  Using  SAF  makes  it  possible  to  run 
larger  exercises  without  having  to  mem  every 
vehicle. 


PDU 

POSNAV 

RIU 

RWA 

52 

53 
SAF 
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SAF  Sim  The  back  end  of  the  Semi -Automated  Forces  System, 
it  runs  the  software  model  of  the  vehicle  and 
associated  weapons  systems,  simulating  the  vehicles 
requested  by  the  user,  and  controlling  their 
actions  in  response  to  the  high-level  commands  from 
the  front  end. 

SAF  Station 

The  front  end  of  the  Semi -Automated  Forces  System, 
it  provides  a  Graphical  User  Interface  GUI  from 
which  the  user  can  create  and  control  groups  of 
vehicles  organized  according  to  the  doctrine  of  the 
armed  forces  of  a  number  of  different  countries. 

see  Simulation  control  console.  The  a  master  console  of 

the  MCC,  used  for  exercise  control. 

SIMNET  SIMulation  Networking;  the  linking  of  simulators 
for  distributed  simulation  exercises  used  for 
tactical  team  training  in  armored  warfare. 

SIMVAD  SIMulated  Voice  Analog/Digital  board;  a  speech  I/O 
board  used  for  converting  voice  from  Analog  to 
Digital,  and  from  Digital  to  Analog. 

SINeGARS  SINgle  Ghannel  Ground/Air  Radio  System.  A  new 

family  of  VHF-FM  combat  network  radios  designed  to 
provide  the  primary  means  of  command  and  control 
for  combat  units,  combat  support  units,  and  combat 
service  support  units  in  the  Army. 

A  table-top  model  is  used  in  the  battalion  TOC  for 
TOC- to- tank  communications.  A  vehicle-based  model 
is  part  of  the  overall  CVCC  tank  simulation  and  is 
used  for  tank-to-tank  and  tank-to-TOC 
communications . 

SitDisp  The  electronic  situation  display 

Steer-to  display 

Display  mounted  next  to  the  T-bar  steering  wheel  in 
the  driver's  conpartment. 

STRICOM  Simulation,  Training  and  Instrumentation  Command 

TACOM  U .  £ .  Army  Tank  and  Automot  i ve  Command 

TCU  Transportable  Conputer  Unit 
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Tethering 


TO 

TOC 

TOOE 

TPRs 

UTM 

XO 


Process  of  tying  a  manned  or  unmanned  simulator  to 
another  maned  or  unmanned  simulator 

Task  Organization 

Tactical  Operations  Center 

Task  Organization  cind  Operational  Effectiveness 
Target  Reference  Points 
Universal  Transverse  Mercator 
Executive  Officer 
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APPENDIX  B:  THE  SIOOO  TERRAIN  DATABASE  GENERATION  PROCESS 


Initially,  SIOOO  database  modeling  tasks  must  be  done 
sequentially.  In  the  design  task,  data  are  collected  from 
the  real  world  location  and  the  database  is  carefully  defined 
in  accordance  with  customer  needs  and  CIG  processing 
capability.  Population  parameters,  such  as  object  density 
and  priority,  are  established  using  this  information.  These 
two  steps,  site  data  collection  and  database  definition,  must 
occur  before  construction  begins.  Land  creation  is  the  first 
construction  step,  followed  by  road  and  river  development. 
After  this  step,  the  other  processes  may  be  carried  out  along 
parallel  paths. 

Three  dimensional  objects  such  as  buildings  and  vehicles  are 
created  from  drawings,  photos,  and  scaled  models.  They  can 
be  placed  on  the  terrain  as  static  objects,  or  stored  in  a 
Dynamic  Element  Database  (DED) .  These  objects  are  enhanced 
by  the  application  of  textures. 

Textures  are  created  at  the  same  time  models  are  being 
developed.  Color  images  are  entered  into  the  computer  from  a 
variety  of  sources,  such  as  photographs.  They  are  processed 
and  loaded  on  the  simulator  hardware.  A  texture  set  contains 
approximately  150  unique  entities,  each  producing  additional 
apparent  scene  complexity,  thereby  providing  more  realism. 

A  three  dimensional  effect  is  produced  by  each  two- 
dimensional  "rotating-stamp"  model  for  objects  such  as  trees. 
The  development  process  involves  formation  of  a  single 
polygon,  and  the  application  of  a  texture.  This  is 
especially  useful  in  the  development  of  foliage  and 
explosions . 

While  models  are  created  and  textures  are  developed,  objects 
can  be  placed  on  the  pre-existing  land  as  an  ongoing 
population  process.  This  is  the  most  time  consuming, 
subjective  part  of  the  database  modeling  process.  Population 
requires  constant  consideration  of  a  variety  of  variables. 
Judgements  are  made  as  to  what  is  most  important  to  include 
in  each  location  for  maximum  training  value  within  the  CIG 
constraints . 

At  the  completion  of  the  population  process,  topological  maps 
are  plotted  for  use  in  navigation  and  combat  training.  Each 
map  is  an  accurate  depiction  of  the  data  contained  in  that 
location  of  the  terrain  database.  Maps  can  be  mass-produced 
by  a  print  shop,  or  printed  at  Loral  in  small  numbers. 

Each  phase  mentioned  above  is  iterative,  involving  numerous 
development-testing  cycles,  and  customer  reviews.  Since  each 
database  construction  project  involves  trade-offs  between  the 
creation  of  a  realistic  scene  and  the  processing  capability 
of  the  simulator,  it  is  essential  for  all  participants  to 
have  a  complete  understanding  of  the  goals,  options,  and 
constraints  of  the  CIG  system. 

There  are  limits  to  the  processing  capability  of  the  CIG, 
which  is  directly  affected  by  the  desired  number  of  active 
dynamic  objects,  frame  update  rate  of  the  display,  field-of- 
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view,  and  viewing  range.  This  processing  capability  must  be 
considered  to  include  only  objects  that  will  provide  the  most 
training  value,  based  on  customer  participation  in  the 
development  process. 
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APPENDIX  C:  RUNTIME  PARAMETERS 


Terrain  Plane  Colors 

The  colors  used  by  the  Color  System  Submodule  may  be  configured 
by  the  user  in  the  "Bntoc"  or  "CCD"  xrexource  file.  The  available  list  of 
named  colors  to  which  the  features  may  be  set  is  located  in  the  file 
/usr/openwin/lib/rgb.txt  (use  the  capitalized  names).  The  following 
specifies  sample  settings  for  all  the  Color  Submodule  resources  that 
may  be  set; 

Table  3 

Terrain  plane  colors 


Parajneter  Name 

Explanation 

Default  Value 

*dirtColor : 

used  to  set  terrain 
background  color 

Wheat 

'*buildingColor ; 

used  to  set 
building  color 

Black 

*fordColor : 

used  to  set 
fordable  water 
color 

SkyBlue 

*riverColor : 

used  to  set  non- 
fordable  water 
color 

Blue 

*roadColor : 

used  to  set  road 
color 

Red 

*treeColor : 

used  to  set 
vegetation  color 

Fores tGreen 

* loContourColor : 

used  to  set  low 
contour  line  color 

Black 

*hiContourColor : 

used  to  set  high 
contour  line  color 

Black 

*gridColor : 

used  to  set  grid 
line  color 

Black 
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Application  Plane  Colors 


Table  4 

Application  plane  colors 


Parameter  Name 

Explanation 

Default  Value 

*  f r iendlyColor : 

friendly  icons  and  ccrtrol 
measures 

Blue 

*enemyColor : 

enemy  icons  and  control 
measures 

Red 

*neutralColor : 

neutral  icons  and  control 
measures 

Black 

*obstacleColor : 

obstacles 

ForestGreen 

*tagColor : 

tags  on  friendly,  enemy, 
and  neutral  icons  and 
control  measures 

Black 

*selectionColor : 

used  to  indicate  a  selected 
object  on  an  overlays 

Black 

*rubberColor : 

used  to  draw  rubber-banding 
box  to  select  object  on  an 
overlay 

Black 

*hiliteColor ; 

used  to  highlight  icons 
corresponding  to  messages 
being  read 

White 

*navColor : 

used  to  draw  POSNAV  routes 

Black 

*blinkFr iendlyColor : 

used  in  CCD  to  draw  icons 
for  newly  arrived  messages 

Blue 

*blinkEnemyColor : 

used  in  CCD  to  draw  icons 
for  newly  arrived  messages 

Red 

*blinkNeutralColor : 

used  in  CCD  to  draw  icons 
for  newly  arrived  messages 

Black 

*blinkObstacleColor : 

used  in  CCD  to  draw  icons 
for  newly  arrived  messages 

ForestGreen 
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Outlier  Pareuneterization 


The  following  table  lists  unit  levels  and  the  default  distance  setting 
in  meters  from  the  center-of-mass  beyond  which  vehicles  are 
considered  outliers: 

Table  5 

Unit  levels  and  default  distance  settings  used  to  determine 
outliers 


Unit  Level 

Default 

Distance 

Section 

750 

Platoon 

750 

Company 

1750 

Battalion 

5000 
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Software  Switch  and  Commands  Catalog 

Background 

The  Fort  Knox  Field  Unit  of  the  U.S.  Army  Research  Institute  for  Behavioral  and  Social 
Sciences  (ARI)  investigates  training  requirements  for  the  Future  Integrated  Battlefield,  using  soldier- 
in-the-loop  simulation.  The  Combat  Vehicle  Command  and  Control  (CVCC)  Project  research 
program  investigates  advanced  digital  and  thermal  technologies  to  enhance  mounted  forces’  command, 
control,  and  communications  (C3)  oqpabilities. 

As  part  of  ARI-Knox’s  research  efforts  concerning  training  requirements  for  future  tank 
technologies  an  automated  link  from  tanks  to  the  battalion  tactical  operations  center  (TOC)  was 
included  as  part  of  the  CVCC  project.  The  effort  also  derived  some  information  concerning  the  delta 
in  operational  effectiveness  which  future  technologies  may  provide.  Two  series  of  battalion  level 
simulations  were  conducted.  These  efforts  included:  the  development  of  information  on  problematic 
training  areas,  preliminary  training  requirements,  soldier-machine  interface  issues  and  assessments  of 
workload. 

The  systems  simulated  combined  in  the  CVCC  research  are  a  Position  Navigation  System 
(POSNAV),  and  a  Command  and  Control  Display  (CCD)  (the  POSNAV  is  embedded  in  the  CCD), 
Further  POSNAV  information  is  displayed  on  a  tank  driver’s  Steer-to-Display.  Additionally,  the 
simulation  includes  a  Commander’s  Independent  Thermal  Viewer  (CflV),  and  the  Single  Channel 
Ground  and  Air  Radio  System  Radios.  A  simulation  of  an  automated  battalion  level  TOC  provided 
the  c^ability  for  digital  commurtications  between  commanders  (battalion  and  conq)any)  mounted  in 
tank  simulators  and  the  battalion  staff.  This  TOC  was  equipped  with  computerized  workstations  for 
Planning  (Executive  Officer),  Intelligence  (S-2  Officer),  Operations  (S-3  Officer),  and  Fire  Support 
(Fire  Support  Coordinator). 

Computer  software  was  developed  to  support  the  simulation  of  the  functions  required  for  the 
formative  evaluation  of  such  a  system.  In  genersd,  the  software  is  in  modular  form  and  provides  the 
capability  to  configure  both  the  tank  simulators  and  the  TOC  computerized  workstations  to  fit  the 
functionality  required.  Incorporated  into  the  simulation  software  are  software  switches  which  allow 
various  capabilities  of  the  software  to  be  exercised. 


fumssE 

The  purpose  of  this  catalog  is  to  provide  a  concise  conq)ilation  of  the  software  switches  and 
commands  which  can  be  used  to  configure  the  CVCC  simulation  software.  In  addition,  there  are  two 
procedural  descriptions  provided. 

(1)  CVCC  Command  Line  Options  describes  the  CVCC  command  line  options  which 
are  supported  for  the  TOC  and  CCD  processes. 

(2)  Connecting  Simulated  SINCGARS  Radios  to  TOC  Workstations 

describes  the  procedure  to  connect  SINCGARS  simulators  to  a  specific  TOC  workstation  so  that  the 
digital  radio  transmissions  originate  at  the  proper  location  on  the  terrain  data  base. 
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CVCC  BnTOC  and  CCD  Conunand  Line  Options 


This  section  describes  the  CVCC  command  line  options  which  are 
supported  for  the  BnTOC  and  CCD  processes. 

The  CVCC  BnTOC  and  CCD  processes  are  ct^able  of  providing  a  summary  of  supported 
command-line  switches.  To  see  the  list  of  available  options,  invoke  the  process  (BnTOC  or  CCD) 
with  the  -help  command-line  switch. 

The  process  will  print  the  list  of  available  options  and  terminate. 

Similarly,  if  the  user  supplies  an  unsupported  command  line  option  to  a  CVCC  process,  it  will  print 
the  list  of  supported  options  and  terminate. 

The  options  consist  of  three  classes:  generic  options,  which  are 
supported  by  both  the  BnTOC  and  CCD,  BnTOC-specific  options,  and 
ccd-specific  options.  When  the  supported  options  are  listed,  the 

generic  options  are  described  first,  followed  by  the  options  which  are  specifically  supported  by  the 
type  of  process  (BnTOC  or  CCD)  which  was  invoked  by  the  user. 

The  command  line  summary  which  is  printed  (with  options  listed 
alphabetically)  is  as  follows: 

Usage:  <process_name>  [-options  ...] 


GENERIC  CVCC  OPTIONS 

Software  Switch  Option 

-active  <  dirNarae  > :  Specifies  the  name  of  the  active 

directory  of  the  CVCC  data  directory. 
-caliSign  <callSign> :  Speciftes  the  call  sign  of  the  simulator. 

Overrides  the  network  configuration  file. 

This  option  is  used  to  change  the  callsign 
which  is  automatically  filled  in  for 
digital  messages.  The  callsign  can  be 
edited  manually  for  each  message.  However, 
if  the  exercise  calls  for  an  officer  to  be 
located  in  a  tank  where  he  would  not  by 
default  be  located,  using  this  option  will 
facilitate  the  generation  of  reports. 

-chptFile  <fileName> :  Startup  using  runtime  state  in  specified 

checkpoint  file. 

-clq>tHome  <  dirName  > :  Specifies  directory  to  find  checkpoint 

files. 

-comNone:  C2  data  comms  disabled. 

-comEthemet:  C2  data  comms  broadcast  on  ethemet. 
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•comRadio:  C2  data  conum  using  SINCGARS  radios. 

-comNoNet:  C2  data  not  sent. 

-configFile  <fi}eNaine> :  Specifies  network  cotiHguration  file. 

-cpradius  <dist> ;  Set  radius  for  selecting  cone  pts  to 

dist.  This  option  is  used  to  calibrate 
the  maximum  distance  used  for  selecting 
a  concentration  point  when  the  user 
Alls  out  a  Call  For  Fire  message.  If 
the  distance  from  the  cursor  to  the 
nearest  concentration  point  on  the 
screen  exceeds  the  specified  distance, 
the  location  of  the  cursor  is  used  in 
filling  out  the  location  field.  Other 
wise,  the  location  of  the  nearest 
concentration  point  is  used. 

-debug  <  flags  > :  Specifies  debug  flags. 

-dutyPosition  <dp> :  Specifles  the  duty  position  of  the  simu¬ 

lator.  Overrides  the  network  configura¬ 
tion  file. 

-exercise  <  exerciselD  > :  Exercise  ID  this  system  is  participating  in. 

-fresh:  Startup  using  a  fresh  runtime  state. 

-loopback.  Loop  C2  messages  back  to  the  message  queue. 

-memory:  Use  memory  allocator  to  And  memory  leaks. 

-netDevice  <devName> :  Specifies  the  simulation  network  device. 

-nice  <num>:  See -proccssPriority. 

-proccssPriority  <num>:  Specifies  process  priority.  Valid  range 

of  <num>  is  1  - 10,  10  highest. 

-recover:  Startup  using  the  active  runtime  state. 

-rootDir  <dirName> :  Specifles  root  directory  of  CVCC  data 

directory. 

-same:  Run  with  all  dialogues  on  the  same  screen. 

-sw^:  Swap  the  screens  used  to  display  dialogues. 

-tooeFile  <  flleName> :  Specifles  task  organization  configuration  file. 

-version:  Print  the  current  version  number  and  exit. 

These  options  all  affect  the  initial  state  of  the  process.  The  -fresh  option  is  used  to  insure  that  all 
prior  messages,  saved  and  posted  overlays,  map  state  (zoom  level,  scrolled  location),  and  other 
context  are  cleared. 

The  -chptFile  option  allows  the  iwer  to  specify  the  name  of  a  CVCC  checkpoint  to  use  for  reestablish¬ 
ing  the  process  context  upon  startup. 

The  -chptHome  option  may  be  used  in  conjunction  with  the  -chptFile  option  to  specify  a  non-default 
location  for  the  checkpoint  file  (this  may  be  necessary  due  to  disk  storage  constraints). 

The  -recover  option  is  used  to  recover  the  context  of  the  previously  run  CVCC  process.  This  option 
is  used  primarily  to  recover  from  an  accidental  termination  of  a  CVCC  process  during  an  exercise. 
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-exercise  <exerciseID> ;  Exercise  ID  this  system  is  participating  in. 

This  option  is  used  to  set  the  exercise  ID  of  ^e  exercise  which  the  CVCC  process  will  participate  in. 
Setting  the  exercise  ID  on  the  command  line  will  override  any  settings  which  may  exist  in  resource 
files. 

-comNone:  C2  data  comms  disabled. 

-comEthemet;  C2  data  comms  broadcast  on  ethemet. 

-comRadio;  C2  data  comms  using  SINCGARS  radios. 

-comNoNet:  C2  data  not  sent. 

-communication  <  mode  >:  Specifies  communication  mode.  Valid 

values  include  NoNet,  Ethemet,  RIU. 

These  options  all  support  the  selection  of  a  communications  mode. 

Normal  modes  for  an  exercise  are  -comRadio  and  -comEthemet.  A  CVCC  process  operating  in 
comRadio  mode  will  atten^it  to  send  digital  messages  using  a  SINCGARS  radio  simulator  (which  is 
configured  in  resource  files).  CVCC  processes  operating  in  comRadio  mode  are  still  capable  of 
receiving  messages  from  CVCC  processes  operating  in  comEthemet  mode.  A  CVCC  process 
operating  in  comEthemet  mode  will  send  messages  directly  to  other  CVCC  processes  over  the 
Ethemet.  This  mode  of  operation  is  useful  if  no  SINCGAJ(S  radio  simulator  is  available  for  that 
process.  CVCC  processes  operating  in  comEthemet  mode  are  still  capable  of  receiving  messages 
from  CVCC  processes  operating  in  comRadio  mode.  The  comNone  mode  supports  a  special  training 
mode  in  which  the  operator  is  not  allowed  to  send  digital  messages.  Currently,  this  m^e  is  only 
used  for  the  CCD.  The  CCD  user  interface  appears  different  in  this  mode  and  denies  the  user  the 
ability  to  send  messages.  Lastly,  the  comNoNct  option  is  useful  for  running  a  CVCC  process 
(possibly  for  a  demo)  on  a  workstation  which  is  not  connected  to  an  Ethemet.  If  this  option  is  not 
provided,  the  CVCC  process  will  teiminate  upon  failure  to  access  the  Ethemet  driver. 

Note  that  the  "-communication"  flag  followed  by  a  mode  name  is  an 
alternative  way  of  specifying  the  communications  mode. 

-same:  Run  with  all  dialogues  on  the  same  screen. 

-swap:  Swap  the  screens  used  to  display  dialogues. 

These  options  are  used  to  determine  which  modules  of  the  CVCC  process  are  displayed  on  which 
monitor  for  a  dual-headed  workstation.  The  -same  option  causes  all  modules  to  create  windows  on 
the  same  monitor.  Since  the  CCD  cunently  only  uses  one  monitor,  this  option  has  no  effect  on  it. 
The  -swap  option  is  used  to  switch  the  monitor  which  each  module  is  displayed  on  by  default  to  the 
other  monitor. 

-version:  Print  the  current  version  number  and  exit. 

This  option  is  used  to  verify  that  the  proper  version  of  software  is  being  used. 


The  following  options  control  the  mode  of  execution  of  the  battalion  TOC  workstations. 
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Software  Switch  QcliSD 
-coordinator:  Run  as  the  checkpoint  coordinator. 

This  option  is  used  to  start  the  BnT(X!  with  the  checkpoint  functionality  accessible  from  the  main 
menubar.  Any  BnTOC  work-station  can  use  this  flag,  however,  traditionally  the  SitDisp  is  used  as 
the  coordinator. 


-develop: 

-normal: 

-nofint: 

-notooe: 

-nomap: 

-nomsg: 

-notools: 

-notdb: 


Rtm  in  development  mode. 

Run  in  normal  mode. 

Run  without  the  format  module. 
Run  without  the  TO/OE  module. 
Run  without  the  map  module. 
Run  without  the  message  module. 
Run  without  the  tools. 

Run  without  the  terrain. 


Each  of  the  above  flags  is  used  to  run  the  BnTOC  without  the  specified  module.  These  flags  are  used 
to  allow  the  BnTOC  to  be  brought  up  more  quickly  and  prevent  the  windows  from  cluttering  the 
screen  during  developmental  testing.  These  flags  are  not  supported  for  normal  operations.  Running 
without  all  modules  could  cause  inqiroper  behavior  and  even  failure  (crashes)  under  certain 
conditions. 


Command  and  Control  Display  Specific  Potions: 
The  following  options  control  the  mode  of  execution  of  die  CCD. 


Software  Switch 


Option 


ndevelop: 

-baseline: 

-enhanced: 


-experimental: 


Run  in  custom  developmental  mode. 

Run  in  baseline  mode.  Monochrome  display,  C3  digital  comms  disabled,  touch 
screen  disabled,  maqi  functions  limited,  map  features  limited  to  grid  lines. 

Run  in  enhanced  baseline  mode.  Full  color  display,  C3  digital  comms 
disabled,  touch  screen  disabled,  map  functions  limit^.  Map  features  limited  to 
grid  lines. 

Run  in  experimental  mode  (DEFAULT  MODE). 

Full  color  display,  C3  digital  comms  enabled.  Touch  screen  enabled,  map  fully 
enabled. 


The  user  should  choose  a  mode  in  which  to  run  the  CCD.  Normally,  the  mode  will  be  set  in  a 
resource  file,  using  the  '*'executionMode  resource.  The  "-develop"  mode  should  only  be  used  by 
developers.  Historically,  CCD  experiments  and  demos  are  run  using  "-experimental"  mode,  which 
provides  full  functionality  and  display  c^abilities.  The  "-baseline"  and  "-enhanced"  baseline  modes 
support  alternative  levels  of  restricted  functionality. 

-innovate:  Innovative  training  exercise. 

The  "-innovate"  command  line  switch  is  used  to  support  a  special  mode  for  using  the  CCD  for 
innovative  training  exercises. 
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-color;  Overrides  mode  setting  on  color  setting.  Use  full  color  display. 

-monochrome:  Overrides  mode  setting  on  color  setting.  Use  monochrome  (amber  and 

black)  color  display. 

By  default,  the  selected  CCD  mode  will  determine  whether  the  CCD  is  displayed  in  full  color  cr 
monochrome  mode.  These  command  line  flags  can  be  used  to  override  the  default  associated  with  the 
mode  the  CCD  will  be  using. 

-mouse;  Overrides  mode  setting  on  input  devices.  Enables  mouse  as  input  device. 

-touch;  Overrides  mode  setting  on  input  devices.  Enables  touch  screen  as  input  device, 

-handle:  Overrides  mode  setting  on  input  devices.  Enables  commander’s  handle  as  input 

device. 

By  default,  the  selected  CCD  mode  will  determine  which  input  devices  will  be  enabled. 

The  "-mouse"  command  line  option  is  used  to  explicitly  enable  the  mouse  as  an  input  device, 
regardless  of  the  mode. 

Similarly,  the  "-touch"  command  line  option  is  used  to  explicitly  enable  to  touch  screen.  The 
"-handle"  command  line  option  performs  the  same  function  for  the  commander’s  handle. 

-grid;  Override  mode  setting  on  map  features.  Display  of  map  features  limited  to 

grid  lines. 

-map;  Overrides  mode  setting  on  map  functions.  Map  features  and  map  functions 

fully  enabled. 

By  default,  the  selected  CCD  mode  will  determine  which  features  are  displayed  by  the  map,  either  the 
full  set  of  m^  features  or  just  the  grid  lines.  These  options  are  used  to  override  the  defaults  used  by 
the  current  CCD  mode. 

-confine:  Confine  pointer  to  CCD/IVIS. 

This  command  line  option  is  used  to  prevent  the  cursor  on  the  CCD  screen  from  leaving  the  window 
which  contains  the  CCD  (and  potentially  getting  "lost"  or  providing  unintended  access  to  workstation 
functions).  This  option  is  normally  set  using  the  *pointerConfmed  resource,  and  should  be  used  for 
exercises. 

-isolate:  Prevent  reception  of  C3  comms  from  Co  networks. 

This  command  line  option  is  used  to  isolate  the  CCD  from  any  traffic  on  the  company  networks. 

Other  networks  are  unaffected. 

-standalone:  Run  without  vehicle  simulator. 

-location  <  UTM  locn> :  Starting  location  for  our  own  tank. 

-attached:  Run  witli  vehicle  simulator. 

The  "-standalone"  command  line  option  allows  the  CCD  to  operate  without  a  CVCC  simulator.  This 
is  useful  for  giving  demos  of  the  CCD,  since  otherwise  the  "own  tank"  icon  will  never  appear. 
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The  "-location"  command  line  option  is  used  in  conjunction  with  the  "-standalone"  option  to  select  the 

location  of  the  own  tank  icon.  By  default,  the  CCD  tries  to  attach  to  a  vehicle,  which  may  be 

specified  explicitly  with  the  "-attached"  command  line  switch. 

'grid:  Override  mode  setting  on  map  features.  Display  of  map  features  limited  to  grid 

lines. 

-handle:  Overrides  mode  setting  on  input  devices.  Enables  commander’s  handle  as  input 

device. 

-m^:  Overrides  mode  setting  on  map  functions.  Map  features  and  map  functions  fully 

enabled. 

-monochrome:  Overrides  mode  setting  on  color  setting.  Use  monochrome  (amber  and 

black)  color  display. 

-mouse:  Overrides  mode  setting  on  input  devices.  Enables  mouse  as  input  device. 

-location  <  UTM  locn> :  Starting  location  for  our  own  tank. 

-normal:  Run  in  experimental  mode. 

-notdb:  Override  mode  setting  on  map  features.  Display  of  map  features  limited  to  grid 

lines. 

-touch:  Overrides  mode  setting  on  input  devices.  Enables  touch  screen  as  input  device. 
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Miscellaneous  CCD  Software  Switch  Options 


The  following  are  miscellaneous  options. 


Software  SwitchOotion 


-confine: 

-driverport: 

-isolate: 

-standalone: 


Confine  pointer  to  CCD/IVIS. 

Driver  Port  exists. 

Prevent  reception  of  C3  comms  ft-om  Co  networks. 
Run  without  vehicle  simulator. 


While  there  are  a  large  number  of  supported  options,  not  all  options  should  be  used  by  any  user  of 
the  CVCC  processes.  Some  options  will  be  used  routinely  during  CVCC  exercises.  Some  should 
only  be  used  in  special  circumstances.  Some  options  are  only  useful  for  developing  and  debugging. 
The  following  sections  describe  the  CVCC  process  command  line  options  in  further  detail  and 
describe  the  appropriate  circumstances  for  their  usage. 


CVCC  SIMULATION  STARTUP  SWITCHES 


The  following  options  are  CVCC  simulation  startup  switches. 


.S.9ftwarg...Sgiteb 


Option 


-a 

(asymmetric  buffers: receive  send) 

-A 

(Autoloader  Disabled 

-c 

(Override  pars  file) 

-C 

(Citv  debug) 

-d 

(debugging  on) 

-D 

(debugging  for  static  vehicles  on) 

-e 

(ethemet  off) 

-E 

(exercise  id) 

-f 

(fail  no  damage  mode  on) 

-F 

(fail  debug  on) 

-g 

(graphics  off) 

-h 

(help) 

-i 

(iff  enable) 

-1 

(laser  of  citv  enabled) 

-k 

(keyboard  on) 

-m 

(messages  for  equipment  status  not  printed) 

-n 

(network  verbose  mode) 

-N 

-  show  citv  icon  relative  to  grid  north 

-o 

(overrun  printing) 

-P 

(position)  vehicle_number  initial  X  initial_Y  ini 

-P 

(priority  list  debugging  on) 

-r 

(rivers  all  fordable 

-s 

(stack  enable) 

-S 

(set  Network  device) 

tial_heading 
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-t 

-T 

-V 

-V 

.? 


(terrain  database)  database_name 
(ded  database)  database_name 
(verbose  mode  on) 

(CITY  Disabled) 

(help) 


!)VCC  Simulation  Keyboard  Switches 


The  following  options  are  CVCC  simulation  keyboard  switches. 


Software  Switch  Option 
a  :  citv_auto_scan  () 

A  :  print_citv_status  () 

c  :  set  citv  state  =  OTW  DAY 

C  :  set  citv  state  -  OTW  OFF 


fail_suppress_damages_toggle  () 
failj)rint_debug_toggle  () 
citv_mode_gps  () 
citv  mode  citv  () 
electsys_battery_failure  () 
rva_dumpjpriorityJists  0 
togglc_all_vision_blocks  () 
vision_restore_air^blocks  () 
rva_tum_debug_on  () 
rva_tum_debug_off  () 
exit _gracefully  () 
toggle_cmdr_vision_blocks  () 
toggle_ldr_vision_block  () 
toggle_citv_vision_block  (). 
citv_search  () 
stack_printjnfo  () 
drivetrainjransmission  failure  () 
rtc_print_permanent  () 
rtc_8imuI_history  () 
print  view  modes  () 
rtcj)rint_tirae  () 
toggle_dvr_vision_blocks  () 
toggle _gps_vision_block  () 
cig_2d_do_init  ()  () 
dis^ie  EO  () 
enable  EO  () 
sound_reset  () 
fail_cat_kill  () 
fuel_tanks_init  () 
fixing  everything 
network j)rint_statistics  () 
print  tenq)erature  and  power  supplies 
loader’s  periscope  left 
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St,  ; 

loader’s  periscope  right 

*  . 

commander's  cupola  left 

(  : 

commander’s  cupola  right 

A  , 

toggle  gunners  vision 

&.  : 

toggle  drivers  vision 

?  : 

Page  1  of  help 

6  ; 

Page  2  of  help 

7  : 

Page  3  of  help 

8  ; 

Page  4  of  help 

9  ; 

Restore  ammo 

-  : 

timers_status  () 

+  : 

print  CMC  statistics 

; 

zero  CMC  statistics 

»  » 

sendazimuth 

null  azimuth 

}  : 

print  and  reset  bbd  rtc  statistics 

{  : 

print  bbd  rtc  statistics 

<  : 

Current  <x,  y,  z> 

,  ! 

ammojprint  statistics  () 

print  n^^mapped  value 

X  ; 

print  sorted_vehicle_lists  () 

0  : 

in  pivot  steer 

)  : 

out  of  pivot  steer 

»  • 

print_reasons  () 

/  : 

binoculars  on 

; 

binoculars  off 

SINCGARS  Radio  Simulation  Software. 


The  following  options  are  SINCGARS  Radio  simulation  commands. 


Commands: 

network 

simulation 

timing 

riu 

jack 

fp 

simvads 

hardware 

help 

vehicle 

radio 

version 

exit 


-  network  functions 

-  simulation  status 

-  timing  functions 

-  RIU  functions 

-  jack  functions 

•  front  panel  functions 
-  simvads  functions 
'  hardware  functions 

-  parser  editor  help 

-  vehicle  functions 

-  radio  state  information 

-  print  simulator  version  information 
-  exit  program 
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resetfrontpanels 


-  reset  ALL  front  panels 


RADIO  >  vehicle 
Vehicle  Connnands: 

showposition  -  show  position  of  vehicles 

setposition  -  set  position  of  vehicle  for  given  radio 


RADIO  radio 
Radio  Commands: 

showlocal  -  show  local  radio  state 

showremote  ~  show  remote  radio  state 


RADIO  >  version 

Radio  Simulator  Version  =  Knox  v2.2  Thu  Jun  4  14:24:10  EDT  1992 


Connecting  Simulated  SINCGARS  Radios  to  TOC  Workstations 

Configuring  simulated  SINCGARS  radios  to  connect  to  BnTOC  workstations  is  similar  to  that  which 
is  done  for  standalone  CCD  systems.  There  are  three  parameter  file  keywords  of  interest:  attach,  ced 
and  riu.  An  in-depth  explanation  of  these  keywords  appears  in  the  SINCGARS  Simulation  Reference 
provided  to  each  technician  at  CCTB. 

attach 


For  a  BnTOC  workstation,  the  radio  simulation  is  configured  to  generate  vehicle  appearance  PDU’s 
for  a  vehicle  (currently  an  M577)  housing  the  radio.  The  "nothing"  variation  of  the  attach  keyword  is 
used.  It  is  of  the  form: 

attach  <mum>  nothing  <vnum>  (<xloc>  <yloc>) 

where:  <mum>  is  the  number  us^  internally  to  identify  the  simulated  radio  (assigned 

with  the  "radio"  keyword.) 

<vnum>  is  the  vehicle  number  (prepended  with  the  site/host  pair  of  the  radio 
simulation  host  to  produce  a  vehicle  ID.) 

(<xloc> ,  <yloc>)  is  the  location  of  the  vehicle  on  the  terrain. 

example:  attach  2  nothing  101  (40000,  40000) 

causes  the  radio  simulation  software  to  issue  vehicle  appearance  PDU’s  for  an  MS77  at  location 
(400(X),  40(X)0),  and  to  calculate  propagation  loss  for  radio  2  at  this  location. 

It  is  recommended  that  each  radio  be  assigned  a  separate  vehicle,  and  that  each  vehicle  be  situation  at 
least  20  meters  from  its  neighbors.  Note  that  the  only  way  to  modify  location  is  to  change  the 
parameter  file  entry  and  restart  the  simulation  software.  It  was  anticipated  that  a  separate  "BnTOC 
vehicle  simulator"  would  be  developed,  and  the  vehicle  generation  facility  of  the  SINCGARS  software 
was  only  to  be  an  interim  solution,  hence  limited  cap-  ability. 


D-14 


ccd 


BnTOC  workstations  use  the  CCD  simulation  protocol.  Consequently,  the  radio  simulation  is 
conHgured  to  treat  each  BnTOC  as  a  standalone  CCD. 

The  iq)propriate  form  is: 

ccd  <inum>  <site>/<host> 
where: 

<inum>  is  the  number  used  internally  by  the  SINCGARS  simulation  to  identify 
this  CCD/BnTOC. 

<site>/<host>  is  the  site/host  pair  for  the  BnTOC  simulation  host, 
exan^le:  ccd  1  3/50 

designates  the  BnTOC  simulated  by  host  3/50  as  CCD  number  1 . 


riu 

The  riu  keyword  maps  radios  to  CCD/BnTOC  systems. 

The  proper  form  is: 

riu  <mum>  <#radios>  {<rl>  <r2>  ...}  <^ccd’s>  {<il>  <i2>  ...} 
where: 

<  raum>  is  the  intemally-used  number  of  the  RIU  (used  in  the  keyboard  parser 

for  query  and  control). 

<#  radios  >  is  the  number  of  simulation  radios  assigned  to  this  RIU  (1  or  2). 

<rl  >  <r2>  are  the  identifying  numbers  of  the  simulated  radios  (configured 
with  the  radio  keyword)  assigned  to  this  RIU. 

<ft  ccd’s>  is  the  number  of  simulated  CCD/BnTOC  systems  assigned  to  this  RIU 
(typically  1). 

<  il  >  <  i2>  are  the  identifying  numbers  of  the  simulated  CCD/BnTOC  systems 

assigned  to  this  RIU,  as  configured  with  the  CCD  keyword. 

exanqile:  riu  1  1  2  1  1 

assigns  RIU  1  to  connect  one  radio,  number  2,  to  one  CCD,  number  1. 
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Following  are  the  Listen  Program  Switches. 

CVCC-Listen  < exercise  id>...  [options] 
Where  the  options  are; 


Switch  Option 

>  reports  and  routes  <  = 
adjust  fire  reports 
call  for  fire  reports 
contact  reports 
free  text  reports 
Intel  reports 
nbc  reports 
ivis  routes 
shell  reports 
situation  reports 
spot  reports 

all  reports  and  ivis  routes 

=  >  info  messages  <  = 

ivis  vehicle  status  information  packets 
task  organization  information 
bntoc  utm  location 
commands  to  the  situation  display 
all  info  messages 

(NOTE;  Requesting  tasking,  bnutm  or  siulisp  will 
turn  all  three  of  these  options  on.) 

=  >  execution  control  <  == 
exec  execution  control  messages  (checkpoint 

and  shutdown) 


=  >  citv  packets  <  = 


citvo 

citv  orientation 

citvi 

citv  instrumentation 

=  >  overlays  <  = 

overlay 

an  overlay  control  message  (begin  and 

end  overlay) 

point 

an  overlay  point  symbol 

poly 

an  overlay  poly  line 

mostext 

overlay  text 

mosdb 

mos  link  to  a  database  object 

mosall 

all  overlay  packets 

status 

tasking 

bnutm 

sitdisp 

allinfo 


adjust 

eff 

contact 

freetext 

intel 

nbc 

route 

shell 

sit 

spot 

all 
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>  ivis  instnimentation  <  = 

iirg  ivis  rqx>rt  generation  iastrumentation 

iimsg  ivis  message  instrumentation 

iimap  ivis  nu^  instrumentation 

iiqty  ivis  quantity  instrumentation 

iial!  all  ivis  instrumentation 

==  >  bntoc  instrumentation  <  = 
bimsg  bntoc  message  instrumentation 

bifidr  bntoc  folder  instrumentation 

bimap  bntoc  map  state  and  overlay 

institimentation 

biall  all  bntoc  instrumentation 

CVCC-  =  >  for  innovative  training  <  = 
innotr  displays  iimovative  training  packets 

-  >  for  debugging  communication  with  sincgars  radio  <  - 
sincgars  displays  transmit  respond  and  receive  packets 

=  >  simulator  packets  of  interest  <  = 
vap  vehicle  ^pearance  packets 

laser  laser  range  tinder  packets 

vstat  vehicle  status  packets 

=  >  everything!!  <  = 

allmsg  all  cvcc  messages  (object  and  info) 

allcvcc  all  cvcc  packets  (object  and  info) 

everything  all  packets  pertinent  to  cvcc 

To  choose  the  option,  precede  the  option  name  with  a  ’  + 

To  remove  the  option,  precede  the  option  name  with  a 


The  default  for  CVCC-Listen  is  all  ivis  reports  and  routes. 


Following  are  the  SAFOR  Program  Switches  and  Commands. 


Switches: 

-c 

-d 

-e 

-i 

-n 

-P 


Options 

(cache  terrain  to  speed  startup) 
(debugging  on) 

(exercise  id)  # 

(isolate  connection)  ^ 

(no  network  packets  sent) 

(phantom  commands  debugging  on) 
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-s 

(sleep  occasionally  to  allow  workstation  on  same  machine) 

-t 

(terrain  dbase  to  use)  filename 

-V 

(vehicle  projector  mode) 

>?  or  -h 

(print  help) 

-6 

(version  6.0  simnet  constants) 

-2 

(Ethernet  2  packets  [not  802.3]) 

-z 

(Restore  the  terminal  after  a  program  crash,  and 

-o 

(record  fire  data  to  file  firedata) 

Software  Command 


PHANTOM  <Q  ASHLAND  > 
Commands: 
blaster 
checkpoint 
create 
console 
debug 
exit 

hashing 

het^ 

net 

print 

quit 

reset 

message 

set 

stealth 

vehicle 


-  blast  a  ton  of  vehicles 

•  send  a  checkpoint  message  to  front  end 

-  create  an  echelon 

-  send  a  console  message 

-  debugging  operations 

-  exit  program 

-  simnet  id  hashing  statistics 

•  hejqp  operations 

-  network  commands 

-  print  commands 

-  exit  program 

-  global  phantom  reset :  •♦USE  WITH 
CAUTION** 

-  send  a  message  to  the  Symbolics  screen 
>  set  program  parameters 

-  stealth  operations 

-  vehicle  operationsblaster? 


PHANTOM  ®  ASHLAND  >  blaster  [how  many  platoons  (4  vehicles) 
(Expecting  a  decimal  num^r)] 

PHANTOM  @  ASHLAND  >  checkpoint  [file  name  to  use  (Expecting  a 

string)] 

PHANTOM  @  ASHLAND  >  create 
blue  -  US 

red  -  USSR 


PHANTOM  (S)  ASHLAND >  console  [type  in  message  in  quotes... (Expecting  a  string)] 

PHANTOM  @  ASHLAND  >  hashing 
Options  for  the  hashing  command: 
collect  -  start  collecting  id  hashing  statistics 

report  -  rqwrt  collected  id  hashing  statistics 


exit) 
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PHANTOM  di  ASHLAND  >  heap 
Options  for  the  heap  command; 
collect  -  force  a  collect  on  a  heap 

statistics  -  print  statistics  for  a  heap 

verify  -  verify  the  consistency  of  a  heap 

PHANTOM  ®  ASHLAND  >  net 
Options  for  the  net  command: 
stats  >  print  simnet  statistics 

zero  -  zero  out  the  simnet  statistics 

thresholding  -  get  thresholding  statistics 

PHANTOM  0  ASHLAND  >  print 
Options  for  the  print  command; 
buffers  -  number  of  buffers  allocated 

connections  >  connection  status 

count  -  count  of  vehicles  in  simnet 

exercise  -  exercise  that  this  phantom  is  running  in 

hosts  -  count  of  vehicles  by  hosts 

forces  >  count  of  vehicles  by  force 

overlays  <  overlays 

reactions  -  reactionary  CISes 

sites  •  count  of  vehicles  by  site 

vehicles  -  id’s  of  current  vehicles 

version  -  version  of  phantom  program 

PHANTOM  0  ASHLAND  >  reset 

Please  confirm...:  yes  •  Reset  the  phantom  (WARNING:  THIS  CLEARS  EVERY 
THING) 

no  '  Abort  reset  operation 

PHANTOM  0  ASHLAND  >  message  [Message  to  send  (Expecting  a  string)] 

PHANTOM  0  ASHLAND  >  set 
Options  for  the  set  command: 

command jprinting  -  priming  of  SBX  commands  on/off 

abort_on_crror  -  if  on  error  checks  will  call  abort 

print  j)rot_err  -  if  protocol  version  error  will  report  it 

nan  abort  -  if  FP  PROC  gets  an  exception,  will 

abort  (ON) 

ground_impact_mode  -  display  of  ground  impacts  on/off 

headerj)rinting  -  printing  of  SBX  headers  on/off 

indirect_fire_inode  ••  display  of  indirect  fire  on/off 

monitor  jperiod  -  period  for  scheduler  monitor 

tree-avoidance  -  are  ground  vehicles  allowed  to  avoid 

trees  on/off 

checlqpoim  -  will  CVCC  checkpoint  messages  be  processed, 

on/off 
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PHANTOM  ASHLAND  >  stealth 

Options  for  the  stealth: 


setjick 

>  set  time  in  seconds  for  symbolics  drawing  of 
stealth 

address 

•  set  site  host  pair  for  stealth  to  talk  to 

teleport 

-  send  stealth  to  specified  x  y  location 

attach  Jo 

-  attach  stealth  to  specified  vehicle 

exercise 

•  change  stealth's  exercise  to  specified  number 

mimic 

-  mode  for  stealth,  attach  or  mimic(default) 

PHANTOM  <9  ASHLAND  >  vehicle  [vehicle  id  (Expecting  a  decimal  number)] 


SciniAuwmitg^  Forges  CVCC  Mwsasfi.DffaulLEaiamgtgts- 

The  following  are  default  parameters  which  may  be  used  to  configure  the  way  in  which  the  CVCC 
BLUPOR  tanks  and  scouts  report  their  battlefield  locations  and  combat  actions  using  CVCC  message 
formats.  (Program  Revision  1.1. 2.1) 

BLUPOR  IVIS  (CVCC)  Reporting 
Parameters 

(default_cluster_distance  1000.&) 

(default_decluster_distance  1200.0 
(default__spot_rep_range_tiireshold  1000.0 
(default_max_rej^)pear_latcncy  600000  (10*60*1000) 

(defoult_sheli_range_thrahold  1000.0 
(default  shell  distant  1000.0 
(defauirshelljatency  300000  ;;;  (5*60*1000) 

(default^report^monitorjime  20000  (2*1(X)0)  no  longer  used 

(defaultjvis_status_interval  5000 (5*1000) 

(default_under_attack_time_threshold  90000  ;;;  (90*1000) 

(default_shooting_range_thre8hold  1800.0 

;;;  default  values  for  amount  of  time  in  msec  it  takes  to  prepare  an  ivis  report  - 
;;;  there  are  times  for  each  rqiort  type  and  an  added  amount  for  attack 
(default_af_prq)are_time  60000  ;;;  (seconds* 1000) 

(default_ammoj[}repare_time  300000 
(default_cff_prepare_time  60000 
(default_contact_prq)are_time  15000 
(default_8helljprq)arcjimc  60000 
(default_sitrepj>repare_time  180000 
(defiiult_spot_prepare_timc  60000 
(default_inteijprepare_time  300000 
(default_frago_prepare_tiroe  300000 
(de£uilt_nbcj)rq)are_tinae  300000 


'  Numbers  showi  in  italics  are  current  default  settings  on  the  CVCC  network 
in  the  MWTB. 
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(<lefiiult_atuckjprepare_tiine  300000) 

;;;  constraint  on  amount  of  time  in  msec  between  reports 
(default  j)latoon_timc_constniint  3000C) 

(default_con»pany_tlme_constraint  45000) 

(default_contact_range  Threshold  750.0) 

<default_contact_timer  ;;;  (3*60*1(X)0) 

;;;l)efault  values  for  relative  priority  of  the  various  type  report  types. 

It  is  assumed  that  there  are  10  report  types. 

;;;  0  is  most  important,  9  is  least  important. 

;;;  No  two  report  types  are  allowed  to  have  the  same  priority  value. 

;;;  A  priority  of  10  (numberReportTypes)  indicates  unknown  priority  and  will  cause  reports  of 
that  type  to  be  ignored. 

;;;  There  are  currently  7  valid  report  types  so  mmt  have  all  values  between  and  including  0  tliru 
6  with  others  set  to  10. 

(default_contact  priority  CP) 

(default_spotj)riority  i) 

(default_cffjpriority  2) 

(defaull_af  jiriority  3) 

(default_shelljpriority  4) 

(default_ainmoj)riority  5) 

(defauit__sitrepj)riority  6) 

(default_intelj)riority  10) 

(default_,fragoj)riority  10) 

(default^nbcjpriority  10) 

Default  values  for  relative  priority  of  the  various  vehicle  types. 

It  is  assumed  that  there  are  9  leg^  vehicle  types. 

A  bigger  value  for  priority  indicates  increasing  importance. 

;;;  The  overall  priority  indicates  increasing  importance. 

;;;  The  overall  priority  of  a  cluster  is  computed  as  sum  over  i  of  the  number  of  vehicles  of  type  i 
times  the  priority  weight  for  vehicle  type  i. 

(default_unkj>ri_weight  5*) 

(default_tankjpri_weigbt  5) 

(default_atgmj)ri_weight  5) 

(default_rwajpri_weight  5) 

(default_fwa_j>ri_weight  5) 

(default_arty_pri_weight  5) 

(default jpcj)ri_weight  5) 

(default„truckj)ri_weight  5) 

(dcfault_troopj)ri_weight  S) 


^  See  Footnote  Nr  l. 
^  See  Footnote  Nr  l. 
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FOREWORD 


The  Army  Research  Institute’s  (ARJ)  Fort  Knox  Field  Unit  in  conjunction  with  the 
Tank  Automotive  Command  RD&E  Center’s  Vetronics  Division,  has  been  working  with  US 
Army  Armor  center  personnel  and  a  team  of  contractors  in  the  Close  Combat  Test  Bed  facility 
to  develop  an  operational,  luturistic,  state  of  the  art  command,  control,  and  communication  test 
bed  at  Fort  Knox.  The  CVCC  test  bed  has  supported  platoon  to  battalion  level  evaluations  of 
both  vehicle  and  Tactical  Operations  Center  (TOC)  soldier  performance  requirements. 
Determining  these  soldier  performance  requirements  is  essential  to  the  development  of  fightable 
systems. 

This  document  is  intended  to  provide  a  listing  of  those  faults  in  the  Combat  Vehicle 
Command  and  Control  software,  which  was  utilized  in  the  series  of  evaluations,  which  were 
conducted  during  the  period  FY  1989  thru  FY  1993,  that  remain  uncorrected  in  the  event  other 
agencies  may  desire  to  utilize  all  or  portions  of  the  software  for  future  evaluations.  Although 
many  faults  discovered  during  the  ARI  evaluations  were  corrected  a  significant  number  were 
set  aside  since  they: 

(1)  Were  determined  to  be  not  critical  to  the  CVCC  evaluations. 

(2)  Were  discovered  so  late  in  the  evaluation  program  that  time/funds  were  not 
available  to  permit  the  changes  to  be  made. 

(3)  Were  determined  to  have  satisfactory  work-arounds  consequently  the  fault  was 
assigned  allow  priority  for  correction. 


POC:  Dr.  Kathleen  Quinkert 
(502)  624-6928 
Autovon  464-6928 
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Reported  Bugs 
for  the 

CVCC  Evaluation  Program 
General 

1.  Following  is  a  listing  of  bugs  which  have  been  reported  and  have  not  yet  been  corrected 
during  the  CVCC  evaluation  program  to  date. 

2.  The  format  used  in  reporting  is  an  adaptation  of  the  format  used  during  the  evaluation 
period  to  track  reported  bugs.  An  explanation  of  the  format  follows; 

ID:  This  is  an  identification  number  assigned  to  track  the  reponed  bug. 

The  number  shown  here  is  a  cross  reference  to  the  master  Change/Bug 
list. 

Type:  Identifies  the  reported  bug. 

Status:  Provides  the  status  correction  of  the  item. 

Pri:  States  the  priority  previously  assigned  to  the  item  through  FY  92. 

Opened;  ITie  date  the  bug  v/as  reported. 

Est:  The  engineer  time  (in  person-days)  that  it  is  estimated  it  will  take  to 

correct  the  bug. 

Closed;  The  date  the  supervising  engineer  reports  that  bug  is  corrected. 

Sys:  The  CVCC  subsystem  in  which  bug  correction  is  required,  (e.g. 

TOC) 

Mod:  The  module  of  the  subsystem  in  which  the  bug  correction  is  to  be 

made.  (e.g.  Overlay  module  of  TOC  WS). 

Short:  A  short  hand  descriptor  of  the  bug. 

Description:  A  fuller  description  and  explanation  of  the  bug  to  assist  the  engineers 

to  better  understand  what  is  desired  or  what  is  the  required  action. 

Note:  Not  all  format  items  will  appear  with  each  item. 

3.  The  bug  listing  following  is  separated  by  the  major  CVCC  systems: 

a.  The  Tactical  Operations  Center  (TOC). 

ID: 

Type: 

Status; 

Opened: 

Sys: 

Mod: 

Description: 


Disposition: 


082 

Bug 

Open  (suspended) 

90/11/28 

TOC 

Motif 

At  random  times,  the  map  scrollbirs  do  not  properly  track  the  cursor;  it 
must  be  carefully  moved  and  released  within  the  slider  area  for  a  panning 
operation  to  complete. 

This  is  a  bug  in  Motif.  We’ll  keep  an  eye  out  for  a  fix  from  ICS. 


ID: 

Tyi>e: 

vStatus; 

Prl: 

Opciwd; 

Gat; 

Closed; 

Sys: 

Mod; 

Short; 

Description; 


084 

Bug 

Open 

3 

90/11/28 

1 

TOC 

mag 

Multiple  routers  for  1  msg. 

Multiple  Route  dialogues  may  be  created  for  the  same  folder  viewer. 


ID: 

Type: 

Status; 

Pri: 

Opened: 

Est: 

Closed; 

Sys: 

Mod: 

Short: 

Description; 


105 

Bug 

Believed  fixed  -  Reopened  11/21/91 
2 

91/01/14 

mtf 

TOC 

Motif 

"Losing  Pointer"  problem. 

BnTOC  W/S  mouse  pointer  stops  working.  Pointer  tracks  only  on  one 
display,  disappearing  when  the  edge  of  that  display  is  reached  and  reappearing 
on  the  opposite  side  of  the  tracked  display  if  the  mouse  continues  to  be 
moved.  No  menus,  buttons  or  other  BnTOC  widgets  operate  when  this 
happens.  The  BnTOC  process  must  be  killed  from  another  workstation. 


Reopened;  The  rare  but  infamous  "Losing  Pointer  Problem"  occurred  once.  The  pointer 
was  stuck  on  one  monitor  and  the  pointer  would  eventually  wrap  around  to  the 
other  side  of  the  same  monitor.  BnTOC  had  to  be  killed  from  another  node 
(as  always  whenever  tliis  happens).  This  is  a  "Motif"  problem. 


ID;  119 

Type:  Bug 

Pri:  2 

Opened:  91/01/14 

Status:  Open  (deferred) 

Est:  5 

Closed: 

Sys:  TOC 

Mod;  msg 

Short:  Local  db  info  wrong  for  remote  msgs. 

Description:  The  Action  Taken  and  Comments  fields  in  remote  viewers  are  incorrect. 

They  show  the  Action  Taken  and  Comments  from  the  messages  stored  on 
the  local  machine  instead  of  the  remote  machine.  These  fields  should  not 
be  present  on  remote  viewers. 
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ID: 

Type: 

Status: 

Pri: 

Opened: 

Est: 

Closed: 

Sys: 

Mod: 

Short: 

Description: 


ID: 

Type: 

Status: 

Pri: 

Opened: 

Est: 

Closed: 

Sys: 

Mod: 

Short: 

Description: 


Disposition: 


ID: 

Type: 

Status: 

Pri: 

Opened: 

Est: 

Closed: 

Sys: 

Mod: 

Short: 

Description: 


ID: 

Type: 

Status: 

Pri: 


221 

Bug 

Open  (deferred) 
N/A 

91/03/27 


TOC 

msg 

User  error  while  filling  in  PLOT  loc. 

SitRep  report  received  from  IVIS  only  posted  one  PLOT  location  to  imp 
even  though  both  were  filled  in. 


226 

Bug 

Open  (deferred) 

2 

91/03/27 

? 

TOC 

map 

Objects  disappear  when  map  scaled. 

During  the  creation  of  one  overlay,  objects  which  were  created  disappeared 
when  the  map  was  scaled  while  still  in  edit  mode.  Bev  witnessed  this  edit 
session.  Subsequent  to  this  session,however,  we  could  not  reproduce  the 
problem. 

Deferred  due  to  non-recurrence. 


245 

Bug 

Open 

2 

91/16/09 

mtf 

TOC 

Motif 

Map  Scroll  Bars  don’t  work  properly. 

Pix  Scroll  Bars.  They  don’t  work  properly.  Before  the  map  will  scroll,  the 
bar  has  to  be  moved  in  the  intended  direction  and  then  back  just  a 
"smidgeon". 


267 

Bug 

Open 

3 
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Opened: 

91/11/21 

Est: 

Closed: 

? 

Sys: 

TOC 

Mod: 

Motif 

Short: 

Eliminate  Motif  defaults. 

Description: 

The  new  R4  Motif  "default"  outlines  are  very  annoying.  In  addition  to 
being  ugly,  they  cause  the  return  key  to  behave  differently  under  different 
conditions.  They  are  also  confusing  in  the  case  the  outlined  field  is  different 
from  the  highlighted  field  in  a  message  composer.  Can  we  disable  this 
"feature"?  Also,  there  is  an  annoying  default  border  around  a  list  item,  which 
is  also  unuseful  and  confusing. 

ID: 

269 

Type: 

Bug 

Status: 

Open 

Pri: 

3 

Opened: 

91/11/21 

Est: 

Closed: 

mtf 

Sys: 

TOC 

Mod: 

Motif 

Short: 

Msg  fields  lose  first  char. 

Description: 

When  the  user  tabs  to  a  new  field  in  a  message  composer  (instead  of  clicking 
with  the  pointer  into  the  field),  the  test  field  subsequently  looses  the  first 
character. 

ID: 

281 

Type: 

Bug 

Status: 

Open 

Pri: 

3 

Opened: 

91/11/21 

Est: 

Closed: 

2 

Sys: 

TOC 

Mod: 

all 

Short: 

Cursor  loc  inconsistent  in  popups. 

Description: 

The  acknowledgement  popups  are  not  consistent  in  terms  of  tlie  cursor 
being  positioned  in  the  default  button.  Sometimes  it  is  placed  there,  other 
times  it  is  just  moved  into  the  popup. 

ID: 

288 

Type: 

Bug 

Status: 

Open 

Pri: 

3 

Opened: 

91/11/21 
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Est: 

Closed; 

Sys: 

Mod: 

Short: 

Description; 


ID: 

Type: 

Status: 

Pri: 

Opened: 

Est; 

Closed: 

Sys: 

Mod: 

Short: 

Description: 


ID: 

Type: 

Status: 

Opened; 

Est: 

Closed: 

Pri: 

Sys; 

Mod: 

Short: 

Description; 


ID; 

Type: 

Status: 

Opened; 

Est: 

Closed; 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


? 

TOC 

X 

Some  icons  asymmetrical. 

Icons  weren’t  all  symmetrical  in  appearance.  This  appears  to  be  a  problem 
with  the  Sun  X  server,  as  they  appear  correctly  on  other  machines. 


289 

Bug 

Open 

3 

91/11/21 

1 

TOC 

graph 

Object  labels  not  unique. 

Object  labels  arc  not  tested  for  uniqueness.  Should  they  be?  Is  this  a 
resource? 


399 

Duplicates  (see  ^245) 

Open 

91/12/05 


3 

TOC 

msq} 

Scroll  bar  is  uipredictable 

Distance  operator  moves  bar  is  not  proportional  to  distance  map  scrolls. 


446 

Bug 

Open 

92/05/21 

5 

3 

BnTOC 

format 

Format  module  needs  instrumentation  and  checkpoint/recovery 
Currently,  neither  checlqwint/recovery  or  instrumentation  is  implemented  for 
the  format  module.  The  following  in  proposed  for  format  instrumentation. 
The  BnTOC  instrumentation  structure  will  get  one  more  kind  -  format  event 
instrumentation.  The  fonnat  structure  will  contain  two  fields  and  a  union. 
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ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


ID: 

Type: 

Status: 

Opened: 


The  two  fields  are  the  format  event  and  a  format  id.  The  format  id  will 
contain  the  role  of  the  host,  the  format  type,  and  the  format  name.  The  union 
is  for  copy  events  which  will  contain  the  source  and  destination  format  id’s. 
The  event  field  represents  the  following  events  -  create,  open,  delete,  copy, 
save  and  close. 


457 

Bug 

Open  (can’t  reproduce) 

92/07/09 

1 

2 

BnTOC 
message  mgr 

Invalid  highlighting  in  folders 

Sometimes  there  is  a  "hanging"  highlight  in  the  inbox.  If  all  the  messages 
in  the  inbox  are  deleted,  die  next  message  that  comes  in  will  be  highlighted. 
When  the  "selected"  button  is  pressed,  a  "select  message  first"  alert  comes  up. 


506 

Bug  (motif  problems) 

Open 

92/09/15 

?? 

?? 

BnTOC 

message 

Message  viewers  have  problems 

Message  viewers  sometimes  do  not  get  built  correctly.  Occasionally  message 
viewers  do  not  get  built  correctly,  and  buttons  or  fields  are  missized,  or 
absent.  Portions  of  message  viewers  are  drawn  off  the  screen  on  the  BnTOC 
Ws.  If  the  top  of  the  viewer  is  off  the  screen  the  message  cannot  be  moved. 
Close  button  sometimes  does  not  ^pear  on  messages  viewed  on  the  BnTOC 
WS  map  display.  The  only  way  to  close  this  is  to  use  the  middle  mouse 
button  on  the  title  bar.  This  causes  a  menu  to  ^pear.  Portions  of  the  create 
format  dialog  box  remain  after  the  message  has  b^n  created,  edited  and 
closed.  Minimizing  the  format  module  and  then  selecting  maximize  get  rid  of 
this.  All  buttons  and  fields  do  not  always  appear  on  the  BnTOC  WS  copy 
dialog  box.  Occasionally,  when  clicking  on  the  copy  overlay  button  on  the 
copy  dialog  box,  the  cursor  went  to  top  of  the  display,  and  Ae  ws  locked  up. 


516 

Bug 

Open  (workaround) 
92/09/15 


1 


Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Shoit; 

Description: 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


1 

BnTOC 

window  manager 
Window  manager  disappears 

Occasionally  the  window  manager  disappears  on  the  right  hand  monitor  of 
the  TOC  ws.  Restarting  the  window  manager  and  toe  program  is  a 
workaround. 


527 

Bug 

Open 

92/09/18 

3 

1 

BnTOC 

msg  aggregation 

Incorrect  shell  report  aggregation 
Conqionents  are  as  follows: 


# 

Loc 

Time 

From 

30 

ES93 168564 

16  1530:28 

C21 

28 

ES93188560 

16  1530:28 

Cll 

19 

ES93268562 

16  1530:28 

C31 

The 

aggregate  reported 

location  unknown,  and  the  if  in  the  tens  of  thousands. 

528 

Bug 

Open 

92/09/18 

5 

1 

BnTOC 
sit  disp 

Sometimes  overlays  don’t  post 

Usually,  overlays  post  to  the  situation  display  just  fine.  Occasional, 
something  gets  out  of  whack,  and  every  attenqjt  to  post  produces  a  popup 
dialog  on  the  sitdisp  saying  the  "file  <name>  can’t  be  found."  Looking  in 
the  sitdisp’s  overlay  directory,  sure  enough,  the  file  isn’t  there.  Diagnostic 
software  was  added  so  if  the  system  command  which  copies  the  file  fails,  it 
will  print  out  a  message  as  to  what  command  failed,  and  what  the  return  code 
is.  No  actions  until  problem  is  reproduced.  Once  this  problem  occurs, 
nobody  can  post  an  overlay  to  the  situation  display.  Taking  the  BnTOC  down 
and  starting  it  up  in  -recover  fixes  the  problem. 
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ID:  530 

Type:  Bug 

Status:  Open 

Opened:  92/09/15 

Est:  1 

Closed: 

Pri:  3 

Sys:  BnTOC 

Mod:  folder 

Short:  Watch  cursor  doesn’t  turn  on 

Description:  Code  was  added  to  flush  the  event  queue  of  button  events  when  there  is  a 
long  wait.  To  signify  that  this  is  a  "no  button  event"  time,  a  watch  cursor 
is  displayed.  For  many  of  the  folder  contexts,  the  watch  cursor  just  doesn’t 
turn  on.  It  does  enter  the  code  (confirmed  with  the  debugger  and  printf  s), 
but  the  cursor  never  changes. 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


532 

Bug 

Open 

92/09/15 

3 

1 

BnTOC 
overlay  text 
Text  gets  hosed 

On  occasion,  with  a  lot  of  stack  manipulation,  the  text  for  the  entire  stack 
of  overlays  gets  hosed.  This  has  been  seen  a  number  of  times,  but  cannot 
be  reliably  reproduced. 


ID:  417 

Type:  Bug 

Status:  Open 

Opened:  92/04/21 

Est:  2 

Closed: 

Pri:  3 

Sys:  IVIS 

Mod:  map 

Short:  Seleaion  by  arrows  doesn’t  work 

Description:  This  is  verified  for  friendly  aggregation.  Since  arrows  don’t  work  at  all  for 
rqmrt  icons,  it’s  uidcnown  if  this  bug  exists  for  report  icons  as  well.  When  a 
de/aggregation  occurs  such  that  an  arrow  is  produced,  the  user  should  be  able 
to  select  the  anow  to  perform  a  de/aggregation  function  on  it.  At  this  time, 
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nothing  happens  when  a  de/aggregation  arrow  is  selected.  Selection  of  reports 
by  arrows  _do_  work. 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


476 

Bug 

Open 

92/07/09 


3 

ms  and  BnTOC 
gr^hics 

Abati  symbol  is  wrong 

The  abati  obstacle  is  not  correct;  the  actual  symbol  is  a  repeated  series  of 
the  individual  symbol  currently  displayed. 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


481 

Bug 

Open 

92/07/09 


1 

mS  and  BnTOC 
fire  support 

More  symbols  than  trp’s  are  fire  support  symbols 

There  are  other  symbols  that  qualify  as  fire  support  symbols. 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


504 

Bug 

Open 

92/09/15 

5 

2 

ccd 

friendly  aggregation 

BnTOC  ws  stops  updating  friendly  icons 

BnTOC  ws  unexpectedly  stops  updating  POSNAV  icons  until  the  program 
is  stqiped  and  restarted  (recovered).  Some  more  anomalous  (perhaps 
with  common  route  to  this  problem)  observed  by  BIS  (as  reported  in  a  note 
to  cjr):  A  rather  peculiar  aggregation  bug  has  shown  up.  It  is  intermittent 
and  non-detenninistic  (our  favorite  kind).  This  strange  behavior  shows  up 
with  sections  and  companies.  Vehicles,  platoons,  and  the  battalion  are  all 
displayed  correctly.  For  some  reason,  sometimes  a  company  headquarters 
section  is  placed  at  the  upper  left  hand  comer  of  the  map.  Scrolling  the  map 
does  not  move  the  unit  onto  the  screen  >  it  stays  perched  in  that  upper  left 
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comer.  One  of  the  members  of  the  section  will  be  shown  as  an  outlier  in  its 
proper  position.  The  section  is  placed  in  the  upper  left  comer.  The  section 
can  be  selected,  and  deaggregatc^  to  vehicles.  Both  vehicles  will  be  displayed 
correctly.  Ttie  company  that  owns  the  section  will  also  show  up  in  the  upper 
left  comer.  When  its  selected,  all  of  its  descendants,  except  the  headquarters 
section,  will  be  displayed  correctly.  If  everything  is  aggregated  into  a 
battalion,  the  battalion  is  placed  correctly.  Here’s  the  weird  part.  There  are 
5  BnTOC’s  running.  Rig^t  now.  2  of  them  are  showing  this  anomalous 
behavior  with  company  A.  Earlier,  only  one  BnTOC  showed  this  problem 
with  conqwny  C.  To  fix  it,  the  BnTOC  is  brought  down  and  brought  back  up 
in  recover  m^e.  The  problem  goes  away. 


ID:  529 

Type;  Bug 

Status:  Open 

Opened:  92/09/18 

Est:  1 

Closed: 

Pri:  1 

Sys:  ccd 

Mod:  posted  icons 

Short:  FLOTs  from  the  sitdisp  can’t  be  selected  for  unpost 

Description;  For  one  particular  sitrep  FLOT,  the  icon  could  not  be  selected  for  unposting. 

Even  selecting  "all"  in  the  unpost  menu  would  not  remove  the  icon.  The  icon 
did  highlight  for  both  selection  methods,  but  did  not  go  away  when  the 
"ui^st"  button  was  pressed. 


fc...CV.CC..SiiaulatQK. 


ID: 

Type: 

Status: 

Opened: 

Est; 

Closed: 

Pri; 

Sys: 

Short: 

Description; 


361 

Bug 

Open 

91/12/05 

? 

1 

SIMS 

Random  firings  with  no  operator  input 

Random  firings  with  no  operator  iiq>ut  (not  simply  anomalous  sounds).  A 
couple  of  confirmed  cases  of  fratricide  resulted  (observed  on  BLUFOR 
workstation). 


ID:  362 

Type:  Bug 

Status:  Open 

Opened:  91/12/05 

Est;  ? 
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Closed: 

Pri: 

Sys: 

Short: 

Description: 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Short: 

Description: 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Short: 

Description: 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Short: 

Description: 


ID: 


1 

SIMS 

Missing/intermit  veh  images  in  driver's  vision  blocks. 

Missing  or  intermittent  vehicle  images  in  driver's  and  loader's  vision  blocks. 
Not  true  bug  (7)  but  serious  problem  occasionally  resulting  in  collisions. 
Attributed  to  overloaded  CIG. 


363 

Bug 

Open 

91/12/05 

? 

1 

SIMS 

One  of  driver's  vision  blocks  sometimes  lapsed  blank. 

One  of  driver's  vision  blocks  sometimes  lapsed  blank  and  neutral  steering 
moved  blank  to  next  vision  block. 


364 

Bug 

Open 

91/12/05 

? 

1 

SIMS 

Bushes  appear  as  white  balls  or  black  boxes  in  vision  blocks. 


365 

Bug 

Open 

91/12/05 

? 

1 

SIMS 

cnv  and  gun  tube  drift  after  gun  slews  from  Designate. 

CITV  and  gun  tube  drift  after  gun  slews  from  Designate  (overshoot?). 

Greater  slew  arc  produces  greater  drift.  Comment  from  General  Heiden:  "I 
have  tried  to  duplicate  this  and  have  not  been  able  to  cause  this  to  happen.  It 
may  be  a  HW  problem  related  to  the  traverse  handle  adjustment. " 


366 
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Type: 

Bug 

Status: 

Open 

Opened: 

91/12/05 

Est: 

Closed: 

? 

Prl: 

1 

Sys: 

SIMS 

Short: 

Sim  resupply  ("9"  key)  resupplies  55  instead  of  40  rounds. 

Description: 

Pressing  "9"  on  back  of  sim  keyboard  resupplies  55»round  ammo  load, 
should  be  modified  to  40-round  load 

ID: 

367 

Type: 

Bug 

Status: 

Open 

Opened: 

91/12/05 

Est: 

Closed: 

? 

Pri: 

1 

Sys: 

SIMS 

Short: 

One  quadrant  of  CITV  display  occasionally  lapsed  blank. 

Description: 

One  quadrant  of  CITV  display  occasionally  lapsed  blank  (green  with  no 
terrain  features). 

ID: 

368 

Type: 

Bug 

Status: 

Open 

Opened: 

91/12/05 

Est: 

Closed: 

5 

Pri: 

1 

Sys: 

SIMS 

Short: 

CITV  initialued  to  out  the  window  view. 

Description: 

When  the  simulation  is  initialized,  the  CITV  occasionally  comes  up  in  out 
the  window  view.  Pushing  the  white  hot/black  hot  switch  enables  the 
thermal  view. 

ID: 

377 

Type: 

Bug 

Status: 

Open 

Pri: 

2 

Opened: 

91/12/05 

Est: 

Closed: 

? 

Sys: 

SIMS 

Short: 

Simulator  reconstitution:  The  2D  portion  of  the  CITV 

Description: 

Simulator  reconstitution:  The  2D  portion  of  the  CITV  does  not  always 
display  correctly  after  a  reconstitution  of  the  simulator.  The  CIG  ne^s  to 
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be  reset  before  each  reconstitution. 


ID: 

Type; 

Status: 

Opened: 

Pri: 

Est: 

Closed: 

Sys: 

Short: 

Description: 


ID: 

Type: 

Status; 

Pri: 

Opened: 

Est: 

Closed: 

Sys: 

Short: 

Description: 


Disposition: 


ID: 

Type: 

Status; 

Pri: 

Opened: 

Est: 

Closed; 

Sys: 

Mod: 

Short: 

Description; 

Disposition: 


378 

Bug 

Open 

91/12/05 

1 

20?  days 
SIMS 

Simulation  hangs  up. 

For  no  apparent  reason,  the  simulation  stops.  The  views  are  still  present, 
but  they  do  not  update.  The  simulation  terminal  gives  no  indication  as  to 
what  has  happened  except  that  it  is  also  hung  up.  Observation;  The  CIG 
needs  to  be  reset  a  couple  of  times  after  this'condition  in  order  for  the 
boot  process  to  pass  the  point  of  "installing  rst4".  Disposition:  NB:  tell 
the  techs  to  reset  tlie  BCS  1  bus  first.  Difficult  to  estimate  unless  we  know 
how  often  this  happens. 


379 

Bug  (see  jl'363) 

Open 

1 

91/12/05 
20?  days 

SIMS 

Vehicles  are  not  seen  from  several  simulators. 

Vehicles  disappearing:  vehicles  are  not  seen  from  several  sims  (4B,  3B, 

2B).  Simulator  vehicles  will  occasionally  drop  out  or  pop  in  and  out.  This 
appears  to  h^pen  to  only  the  sims  and  not  MCC  generated  vehicles  (targets, 
etc.) 

If  there  are  fewer  than  60  vehicles,  than  this  will  require  a  lot  of  investigation. 


380 

Bug 

Open 

1 

91/12/05 

? 

SIMS 

sound 

No  sounds:  For  no  apparent  reason,  all  sounds  drop  out. 
Known  problem  with  Perc  sound  system. 
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ID: 

Type: 

Status: 

Pri: 

Opened: 

Est: 

Closed: 

Sys: 

Short: 

Description: 


381 

Bug 

Open 

1 

91/12/05 

20 

SIMS 

Partial  sounds:  Some  sounds  are  heard  but  others  are  not. 


ID: 

Type: 

Status: 

Pri: 

Opened: 

Est; 

Closed: 

Sys: 

Short: 

Description: 


382 

Bug  (see  ^381) 
Open 
1 

91/12/05 


SIMS 

Continuous  sounds 

When  the  vehicle  is  turned  off,  the  track  movement  sound  continues.  The 
slew  sound  continues  even  though  slewing  has  stopped. 


ID: 

Type: 

Status: 

Pri: 

Opened: 

Est: 

Closed: 

Sys: 

Short: 

Description: 


383 

Bug  (See  ID:  361) 

Open 

2 

91/12/05 

? 

SIMS 

Anomalous  sounds:  When  the  vehicle  steering  bar  is  rotated 
Anomalous  sounds:  When  the  vehicle  steering  bar  is  rotated,  a  gun  firing 
sound  is  heard. 


cL-MCC 


ID: 

388 

Type: 

Bug 

Status: 

Open 

Pri: 

3 

Opened; 

91/12/05 

Est: 

? 

Closed: 

Sys: 

MCC 
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Shoirt;  Defense  option  invalid 

Description:  Upon  startup  of  the  SCC,  the  MCC  can  be  set  to  place  all  vehicles  as  defense. 

Even  though  this  is  done,  the  defense  option  must  still  be  selected  at  each 
reconstitution  screen  because  the  observer  option  will  be  selected  each  time. 


e.  SINCGARS. 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


488 

Bug 

Open 

92/07/09 

?? 

1 

sinegars 

Performance  in  sinegars  is  lacking 

An  240  packet  overlay  takes  8  minutes  27  seconds  to  transmit  using  riu 
mode;  it  takes  less  than  3  seconds  in  broadcast  mode.  A  message  is 
transmitted  almost  instantaneously  in  broadcast  mode;  it  takes  about  2. 1 
seconds  using  the  riu. 


f.  SEND  Utility. 


ID: 

499 

Type: 

Bug 

Status: 

Open 

Opened: 

92/08/06 

Est: 

Closed: 

1 

Pri: 

3 

Sys: 

send 

Mod: 

send 

Short: 

Field  value  keywords  can’t  liave  trailing  whitespace. 

Description: 

This  limitation  relates  to  the  parsing  of  field  value  entries  (keywords). 
Most  lines  in  a  Send  file  follow  the  format:  "Field_Name  field  value 

If  any  characters  are  entered  on  the  line  after  the  field  value,  the  input 
is  not  accepted.  This  is  true  even  if  the  extra  characters  are  invisible 
whitespace,  such  as  space  or  tab  characters.  In  other  words,  a  carriage 
return  must  immediately  follow  the  field_value. 

ID: 

500 

Type: 

Bug 

Status: 

Open 
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0|>onRd; 

Hst: 

Closed; 

Pri: 

Sys: 

Mod: 

Short: 

Description; 


ID: 

Type: 

Status; 

Opened: 

Est; 

Closed; 

Pri: 

Sys: 

Mod; 

Short: 

Description: 


92/08/06 

1 

3 

send 

send 

Single-line  text  fields  require  <CR> . 

This  limitation  relates  to  the  parsing  of  single-line  text  fields.  Text  fields 
include  all  Text,  FreeText,  and  Rationale  fields.  A  single-line  text  field 
follows  the  format:  Field  Name  Here’s  some  short  text.  The  limitation 
is  tliat  a  carriage  return  MUST  follow  the  end  of  the  text.  However,  since 
text  fields  are  always  last  in  a  Send  file,  it  is  easy  to  forget  to  add  the  final 
carriage  return.  Further,  the  file  will  appear  complete,  since  the  final  carriage 
return  is  not  visible. 


533 

Bug 

Open 

92/09/15 

1 

2 

send 

intel  reports 

Obstacle  unknown  gets  wrong  constant 

If  a  user  does  not  specify  what  an  obstacle  is,  obstacle-  >  what  gets  set  to 
SP_IvisTargetTypeUnknown  rather  than  SP_IvisObstacleTypeUnknown 
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APPENDIX  F 


CHANGE  REQUESTS  PENDING  FOR  THE 
COMBAT  VEHICLE  COMMAND  AND  CONTROL  (CVCC)  PROGRAM 
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CHANGE  REQUESTS  FENDING 
for  the 

COMBAT  VEHICLE  COMMAND  and  CONTROL 

(CVCO 

PROGRAM 


UNITED  STATES 

ARMY  RESEARCH  INSTITUTE  US  ARMY  RESEAROi  INSTTFUTE 

FORT  KNOX  HELD  UNIT 
Fort  KnoKt  Kcitfufiiji 


Dr.  KatUecn  Qniiibert 
Dr.  Cari  Licfctdg 


ARI  HELD  UNIT 

FORT  KNOX  BDM  Int’l  Inc. 


Charics  K.  Hddca,  P.E. 
MiU  Gen*  USA  (Rtd) 


17  DcccndMr  1992 
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FOREWORD 


The  Army  Research  Institute’s  (ARI)  Fort  Knox  Field  Unit  in  conjunction  with  the 
Tank  Automotive  Command  RD&E  Center’s  Vetronics  Division,  has  been  working  with  US 
Army  Armor  center  personnel  and  a  team  of  contractors  in  the  Close  Combat  Test  Bed  facility 
to  develop  an  operational,  futuristic,  state  of  the  art  command,  control,  and  communication  test 
bed  at  Fort  Knox.  The  CVCC  test  bed  has  supported  platoon  to  battalion  level  evaluations  of 
both  vehicle  and  Tactical  Operations  Center  (TOC)  soldier  performance  requirements. 
Determining  these  soldier  performance  requirements  is  essential  to  the  development  of  fightable 
systems. 

This  document  is  intended  to  provide  a  listing  of  the  unimplemented  changes  which 
were  identified  as  possible  improvements  in  the  Combat  Vehicle  Command  and  Control 
software  which  was  utilized  in  the  series  of  evaluations  conducted  during  the  period  FY  1989 
thru  FY  1993  in  the  event  other  agencies  may  desire  to  utilize  all  or  portions  of  the  software 
for  future  evaluations.  Although  many  changes  suggested  during  the  ARI  evaluations  were 
implemented  a  significant  number  were  set  aside  since  they; 

(1)  Were  determined  to  be  not  critical  to  the  CVCC  evaluations. 

(2)  Were  discovered  so  late  in  the  evaluation  program  that  time/funds  were  not 
available  to  permit  the  changes  to  be  made. 

(3)  Were  desirable  but  were  assigned  a  low  priority  for  correction. 


POC:  Dr.  Kathleen  Quinkert 
(502)  624-6928 
Autovon  464-6928 
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Change  Requests  Pending 
12/03/90  thru  10/08/92 


1.  Following  is  a  listing  of  changes  which  have  been  requested,  but  not  yet  implemented  for 
the  CVCC  evaluation  program  to  date.  Not  included  in  the  listing  are  features  which  have 
been  defmed  in  the  functional  descriptions  for  the  various  components  being  utilized  in  the 
evaluation;  these  will  be  the  subject  of  a  separate  paper.  The  format  used  is  an  adaptation  of 
the  format  used  during  the  evaluation  period  to  track  changes  requested  oy  both  ARJ  sponsors 
and  by  the  contractor  personnel  responsible  for  the  formative  evaluations. 

ID:  This  is  an  identification  number  assigned  to  track  the  requested 

change.  The  number  shown  is  a  cross  reference  to  the  master 
change/bug  list. 

Type:  Identifies  whether  the  item  is  a  change  request  or  a  reported  bug  (all 

items  on  this  list  are  change  requests. 

Status:  Provides  the  status  of  implementation  of  the  item. 

Pri:  States  the  priority  previously  assigned  to  the  item  through  FY  92. 

Opened:  When  known,  The  date  the  change  was  requested. 

Est:  When  known,  the  engineer  time  (in  person-days)  that  it  is  estimated 

it  will  take  to  implement  the  change. 

Closed:  The  date  the  supervising  engineer  reports  that  the  change  is 

in^lemented. 

Sys:  The  CVCC  subsystem  in  which  the  change  is  to  be  made,  (e.g.: 

TOC,  CITY,  etc.). 

Mod:  The  module  of  the  subsystem  in  which  the  change  is  to  be  made, 

(e.g.:  Overlay,  Format,  etc.). 

Short:  A  short  hand  description  of  the  change. 

Description:  A  fuller  description  and  explanation  of  the  change  to  assist  the 

engineers  to  better  understand  what  is  desired  or  what  is  the  required 
action. 


''Note:  Not  all  format  items  will  appear  with  each  item. 

2.  The  listing  following  is  separated  by  major  CVCC  subsystems  and  modules. 


ID: 

050 

Type: 

Change  Request 

Status: 

Open 

Pri: 

3 

Opened: 

91/03/18 

Est: 

Closed: 

4 

Sys: 

TOC 

Mod: 

All 

Short: 

Popup  dialogues  popdown  inconsistent. 
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Description; 


ID: 

Type: 

Status: 

Pri: 

Opened: 

Est; 

Closed: 

Sys: 

Mod: 

Short: 

Description; 


ID: 

Type: 

Status; 

Opened: 

Sys: 

Mod: 

Description: 


ID: 

Type: 

Status: 

Pri: 

Opened: 

Est: 

Closed: 

Sys: 

Mod: 

Short: 


There  is  an  operational  inconsistency  between  the  Folder  Viewer  and  Map 
Modules.  Operations  like  Send  Overlay  allow  the  dialog  to  remain  active  for 
multiple  sends,  while  operations  like  Copy/Post  cause  the  dialog  to  pop  down. 
Gen  Heiden  says  that  the  SEND  operations  should  all  cause  the  router  dialog 
to  pop  down  after  pressing  SEND.  3/18/91  Fran  says:  "I  think  that  there  are 
more  reasons  for  explicit  closing  of  the  box  than  not,  so  then,  all  boxes 
should  require  an  explicit  closing.  That  inconvenience  is  far  less  than  would 
be  requir^  by  having  to  open  the  box  again  to  repeat  the  action  on  another 
item. 


062 

Request 

Open 

3 

2 

TOC 

map 

Copy  Overlay  shouldn’t  fill  in  name. 

Copy  Overlay  dialog  user  interface  problem.  Selecting  an  overlay  under 
the  Copy  (Overlay  dialog)  function  should  not  enter  the  filename  of  the 
selected  overlay  in  the  newname  box.  This  is  confusing. 


101 

Request 

Open  (deferred) 

90/12/03 

TOC 

map 

Checkpointing  (whether  implicit  or  explicit)  should  save  the  overlay 
currently  being  edited  into  a  tenqwrary  location.  Upon  startup  the 
original  overlay  (i.e.  not  the  temporary  one)  should  appear  in  the  overlay 
stack.  When  die  user  goes  to  edit  this  overlay,  he  or  she  should  have  the 
option  of  continuing  to  edit  the  temporary  overlay  or  of  ignoring  the 
changes  in  the  temporary  and  reverting  back  to  the  original. 


104 

Request 

deferred 

3 

91/08/01 

2 

TOC 

msg 

Restrict  location  fields  to  tbd. 
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Description: 

Location  fields  should  be  restricted  to  only  valid  locations  in  the  terrain 
database. 

ID: 

109 

Type: 

Request 

Pri: 

3 

Opened: 

91/01/14 

Status: 

Open 

Sys: 

TOC 

Mod: 

msg 

Est: 

Closed: 

10 

Short: 

Update  remote  msg  viewers. 

Description: 

Viewers  open  on  remote  workstations  become  obsolete.  (Do  not  update  on 
line). 

ID: 

141 

Type: 

Request 

Status: 

Open 

Pri: 

Opened: 

Est: 

Closed: 

3 

Sys: 

TOC 

Mod: 

all 

Short: 

Support  list  multiple  selection. 

Description: 

BnTOC  software  should  allow  multiple  selection  of  messages,  folders, 
overlays,  and  formats  where-ever  it  makes  sense.  The  multiple  selection 
policy  should  be  consistent  for  all  of  these. 

ID: 

143 

Type: 

Request 

Status: 

deferred 

Pri: 

2 

Opened: 

91/01/21 

Sys: 

TOC 

Mod: 

fmt 

Short: 

New  format  name  didn’t  appear  in  list. 

Description: 

A  saved  format  name  should  appear  in  the  format  module  immediately  after 
it  is  saved.  This  does  work,  but  it  is  confusing  if  the  user  has  a  different 
type  of  format  selected  than  the  newly  saved  format  (in  which  case  the 
new  name  "'shouldn’t'^  ^pear  in  the  list. 

ID: 

156 

Type: 

Request 

Status: 

Open 

F-6 


Pri: 

3 

Opened: 

91/03/14 

Est: 

1 

Closed: 

Sys: 

TOC 

Mod: 

msg 

Short; 

Add  confirmation  to  msg  delete. 

Description; 

Delete  Messages  operation  requires  a  confirmation  dialog 

ID. 

157 

Type: 

Request 

Status: 

Open 

Pri: 

3 

Opened: 

91/03/14 

Est; 

Closed: 

35 

Sys: 

TOC 

Mod: 

clqit 

Short: 

Enhance  checkpoint/restart. 

Description; 

Restarting  does  not  properly  clean  up.  Restarting  does  not  properly 
close  all  open  message  viewers.message  conqiosers,  formats,  and 
subdialogs.  To  be  properly  done,  this  requires  a  two  pass  restart 
mechanism. 

ID: 

170 

Type: 

Request 

Status: 

Opra 

Pri: 

3 

Opened: 

91/03/14 

Est: 

Closed; 

1 

Sys: 

TOC 

Mod: 

msg 

Short: 

Add  Field  Titles  to  the  Folder  Viewers. 

Description: 

Add  a  Field  Title  string  to  the  Folder  Viewers  and  the  Journal  to  explain 
each  of  the  components  of  the  message  summary  strings: 

Status  DTG  Orig  Title  Summary  Action  Taken 

ID: 

184 

Type: 

Request 

Statm: 

Open 

Pri: 

Opened: 

3 

Est: 

Closed: 

1 

Sys; 

TOC 

F-7 


Mod:  workbook 

Short;  Rule-dependant  lists  of  Standard  Folders. 

Description:  Need  to  be  able  to  specify  separate  lists  of  Standard  Workbook  Folders  for 
each  of  the  BnTOC  roles. 


ID: 

Type: 

Status; 

Pri: 

Opened: 

Est: 

Closed: 

Sys: 

Mod; 

Short: 

Description; 


197 

Request 

Open 

3 

91/03/06 

2 

TOC 

map 

Set  unit  size  on  TOC/CP. 

For  unit  symbols,  change  the  unit  TOCs  to  TOC/CP  and  be  able  to  edit  the 
unit  size  field. 


ID: 

Type: 

Status: 

Pri: 

Opened: 

Sys: 

Mod: 

Est; 

Closed: 

Short: 

Description: 


200 

Request 

Open 

3 

91/03/06 

TOC 

nuq) 

3 

Unit  size  should  scale  for  CMs. 

The  unit  size  designator  does  not  scale  for  graphic  control  measures  that 
are  drawn  on  the  map  (i.e. boundaries). 


ID:  203 

Type:  Request 

Status;  Open 

Pri:  3 

Opened;  91/03/06 

Sys:  TOC 

Mod;  map 

Est:  2 

Closed: 

Short:  Make  object  menus  icon-type  sensitive. 

Description:  The  midde  mouse  button  operations  should  be 

disabled  for  margin  arrows  for  the  following  icon  types.  POSNAV  icons  - 
All  functions  disabled.  Report  icons  -  All  functions  except  "View"  should 
be  disabled.  This  is  because  the  rmlting  function  cannot  be  observed 
and  the  function  does  not  make  sense. 
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ID: 

206 

Type: 

Request 

Status: 

Open 

Pri: 

3 

Opened: 

91/03/03 

Est: 

3 

Closed: 

Sys: 

TOC 

Mod: 

msg 

Short: 

Omy  "Route"  btn  when  no  msg  selected. 

Description: 

Need  an  error  dialog  for  "Route"  message  function  when  no  message  is 
selected.  On  the  message  folders,  if  "Route"  is  selected  and  no  repotl 
from  the  list  is  selected,  do  not  bring  up  the  window  associated  with  that 
function.  Since  you  will  eventually  have  tlie  error  message  pop-up,  have 
the  error  pop-up  appear  when  the  function  is  selected  or  disable/shade 
these  functions  until  a  report  is  selected  from  the  list. 

ID: 

212 

Type: 

Request 

Status: 

Open 

Pri: 

3 

Opened: 

91/03/21 

Sys: 

TOC 

Mod: 

fmt 

Short: 

Need  Collection  format  template. 

Description: 

Add  the  Collection  format  template. 

'!D: 

223 

I'ype: 

Request 

Status: 

Open 

Pri: 

3 

Opened: 

91/03/27 

Est: 

1 

Closed: 

Sys: 

TOC 

Mod: 

msg 

Short: 

Clear  the  folder  name  after  each  create. 

Description: 

Clear  the  folder  name  field  in  the  workbook  index  dialog  after  each 
operation.  The  folder  name  field  in  the  workbook  index  dialog  should  be 
cleared  when  the  user  hits  the  create  button  so  that  tlie  user  can  easily 
enter  the  name  of  the  next  folder  to  create. 

ID: 

247 

Type: 

Request 

Status: 

Open 

Pri: 

3 

Opened: 

91/09/16 

F-9 


1 


Est: 

Closed; 

Sys:  TOC 

Mod;  msg 

Short  .  Remove  own  WS  from  REMOTE. 

Description;  Remove  own  WS  from  REMOTE.  Each  WS  has  ail  WSs  on  the  remote 
menu. 

Priority;  LOW 


ID; 

248 

Type; 

Request 

Status; 

deferred 

Pri; 

3 

Opened; 

91/09/16 

Est; 

?? 

Closed; 

Sys; 

TOC 

Short; 

Menu  bars  and  spot  menus  act  different. 

Description; 

Standardize  menu  access.  All  Communications  and  Planning  Display, 

Map  Display,  and  overlay  attribute  menus  are  accessed  by  clicking.  Overlay 
symbol,  report  icon,  and  POSNAV  icon  menus  are  accessed  by  dragging. 
Fran’s  clarification:  All  icon  (POSNAV,  report)  or  overlay  object  menus  are 
accessed  by  dragging  (have  to  hold  the  button  down  to  keep  the  menu  open: 
dragging).  BBN  clarification:  This  is  the  difference  between  how  Motif  menu 
bars  and  spot  work.  Clicking  on  an  item  in  the  menu  bar  brigs  up  a  menu 
that  stays  up.  A  spot  menu  is  removed  as  soon  as  button  released. 

ID; 

249 

Type; 

Request 

Status; 

Open 

Pri: 

3 

Opened; 

91/09/16 

Est: 

1 

Closed; 

Sys: 

TOC 

Mod: 

Motif 

Short: 

Cascading  spot  menus  hard  to  use. 

Description: 

Improve  usability  of  cascading  menus.  These  menus  require  precise  selection. 
If  ^le  cursor  falls  off  the  calling  option  the  second-level  menu  still  appears 
(but  no  selection  from  it  can  be  made).  This  is  probably  an  operating  system 
problem,  but  still  worth  noting.  May  attempt  to  alleviate  problem  by  initially 
placing  cursor  nearer  right-hand-side  of  spot  menu  and/or  use  larger  font  in 
menu. 

ID: 

250 

Type: 

Request 

Status: 

Open 

F-10 


Pri: 

Opened; 

Sys: 

Mod; 

Short; 

Description; 


ID; 

Type; 

Status; 

Pri; 

Opened; 

Sys; 

Mod; 

Short; 

Description; 


ID; 

Type; 

Status; 

Pri; 

Opened; 

Sys; 

Mod; 

Short; 

Description; 


ID; 

Type; 

Status; 

Pri; 

Opened; 

Est; 

Closed; 

Sys; 

Mod; 

Short; 

Description; 


Priority; 


3 

91/09/16 

TOC 

msg 

"Add  conqwnent"  for  aggregates. 

Inclement  "Add  component"  (?).  This  fiinctionality  and  the  concomitant 
"C"  status  code  was  never  implemented.  What  is  its  status?  If  it  will  not 
be  implemented,  then  we  could  do  away  with  the  "Add  Component"  button 
on  aggregate  reports. 


251 

Request 

Open  (deferred) 

1 

91/09/16 

TOC 

msg 

Provide  message  alerts. 

Provide  message  alerts.  Consider  providing  auditory  and  visual  signals 
for  message  receipt. 


252 

Request 

Open  (deferred). 

1 

91/09/16 

TOC 

map 

Provide  UTM  loc  via  mouse  click. 

Provide  UTM  grid  location  on  call  via  the  third  mouse  button. 


253 

Request 

Open  (deferred). 

1 

91/09/16 

8 

TOC 

graph 

In^rove  Add/Delete/Move  point  usability. 

Improve  editing  capabilities  for  graphics  tools.  Add,  Delete,  and  Move 
point  are  really  hard  to  use  on  arrow  tips  and  longer/bigger  control 
measures. 

HIGH.  Fran’s  clarification;  In^rove  editing  capabilities;  The  biggest 
problem  was  the  "point"  editing.  A  more  "mac-like"  interface  is  the 
simple  answer  (look  and  feel,  aside). 


F-11 


ID: 

257 

Type: 

Request 

Status: 

Open 

Pri: 

3 

Opened: 

91/09/16 

Est: 

Closed: 

3 

Sys; 

TLC 

Mod: 

msg 

Short: 

Gray-out  unavailable  menu  options. 

Description: 

Gray-out  nonavailable  menu  option.  For  example,  when  viewing  messages 
the  InFolder,  the  InFoIder  option  in  the  routing  menu  should  be  grayed 
out  (permanently  removed?);  likewise,  routing  menus  called  from  a  folder 
should  have  that  folder  grayed  out. 

ID: 

259 

Type: 

Request 

Status: 

Open 

Pri: 

3 

Opened: 

91/09/16 

Ist: 

Closed: 

5 

Sys: 

TOC 

Mod: 

map 

Short: 

Rotatable  graphics  objects. 

Description: 

Provide  the  ability  to  rotate  graphic  objects. 

ID: 

261 

Type: 

Request 

Status: 

Open 

Pri: 

3 

Opened: 

91/09/16 

Est: 

Closed: 

3 

Sys: 

TOC 

Mod: 

map 

Short: 

Make  POSNAV  spot  menus  blue. 

Description: 

Make  POSNAV  icon  boxes  (i.e.  the  spot  menus  from  which  you  access  the 
aggregate  menu)  BLUE.  Then,  when  editing  you  can  distinguish  them 
from  overlay  objects. 

ID: 

284 

Type: 

Request 

Status: 

open 

Pri: 

3 

Opened: 

91/11/21 

Est: 

1 

F-12 


Closed; 

Sys:  TOC 

Mod:  graph 

Short;  Legend  too  long  in  Journal. 

Description:  In  the  journal  folder,  the  entire  legend  isn’t  visible  unless  the  window  is 

expanded.  Suggestions  included  increasing  the  size  of  the  window  or 
putting  the  legend  on  two  lines. 


ID: 

Type: 

Status: 

Pri: 

Opened; 

Est; 

Closed; 

Sys: 

Mod; 

Short: 

Description: 


287 

Request 

Open 

3 

91/11/21 

1 

TOC 

msg 

Want  feedback  on  <CR>  in  composers. 

When  typing  in  the  "Where"  fields,  the  user  needs  to  hit  return  to  really 
enter  the  values  (for  example,  to  get  the  heading  from  the  map).  There 
should  be  some  feedback  for  this  operation. 


ID: 

Type: 

Status: 

Pri: 

Opened: 

Est: 

Closed: 

Sys: 

Mod; 

Short: 

Description: 


290 

Request 

Open 

3 

91/11/21 

1 

TOC 

msg 

Msg  viewers  hide  others. 

Sometimes,  multiple  message  viewers  are  created  directly  on  top  of  each 
other.  This  is  annoying. 


ID:  292 

Type:  Request 

Status:  Open 

Pri:  3 

Opened:  91/11/21 

Est:  3 

Closed: 

Sys:  TOC 

Mod:  graph 

Short:  Want  area  or  point  zoom-in. 

Description;  People  wanted  the  ability  to  zoom  in  on  a  selected  point  or  area. 
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ID: 

Type: 

Status: 

l»rl: 

Opened: 

Bst: 

Closed: 

Sys: 

Mod: 

Short: 

Description: 


ID: 

Type: 

Status; 

Opened: 

E$t: 

Closed; 

Pri: 

Mod: 

Short: 

Description: 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed; 

Pri: 

Sys; 

Mod: 

Short: 

Description: 


296 

Request 

Open 

3 

91/12/06 

3 


TOC 

fmt 

Collapse  format  directories. 

Store  all  formats  in  the  same  directory.  Don’t  make  the  user  select  a 
format  type  to  operate  within,  Make  all  formats  appear  in  the  list 
simultaneously. 


303 

Request 

Oi^en  (deferred). 

91/12/05 

5 

2 

map 

Embed  the  icon  in  the  arrow  which  points  to  it 

For  some  icons,  when  they  are  outside  the  borders  of  the  map,  an  arrow  is 
drawn  pointing  in  the  direction  of  tlie  location  of  the  icon.  ARI  wants  a 
hands-off  interface,  so  that  the  soldiers  can  see  what  kind  of  icon  the 
arrow  is  pointing  to  without  having  to  select  anything.  Their  recommendation 
i.s  to  draw  tlie  icon  inside  the  arrow.  Once  BnTOC  and  IVIS  code  is  merged, 
IVIS  will  get  BnTOC  style  arrows  for  free,  which  require  the  soldier  to  touch 
the  arrow  to  see  what  it  is.  To  embed  the  icon  in  the  arrow  will  take  an 
additional  person- week. 


369 

Request 

Open 

91/12/05 

? 

3 

TOC 

Message 

Could  not  view  messages  at  remote  WS  if  message  not  relayed. 

Could  not  "Remote"  and  view  messages  in  other  WS  folders  if  those 
messages  had  not  been  relayed.  Heiden  comment.  Introduce  the  ability  to 
"pull"  files  and  folders  other  WS  except  "Work  in  Progress"  files  or  "Draft" 
files.  The  TOC  oflRcer  can  de.signate  a  file  as  a  "Draft"  to  prevent  it  from 
being  readable  from  remote  wi  kstations. 
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ID: 

400 

Type: 

Request 

Status: 

Open 

Opened: 

91/12/05 

Est: 

Closed: 

3-10? 

Pri: 

3 

Sys: 

TOC 

Mod: 

message 

Short: 

Grid  locations  entered  in  reports  via  keyboard  don’t  remain 

Description: 

This  is  a  feature  not  a  bug.  This  should  be  a  request  to  change  the 
message  composers  not  to  require  a  carriage  return  to  enter  a  value. 
However,  this  needs  to  be  examined  in  the  larger  context  of  consistent 
input  into  text  fields  for  all  the  BnTOC. 

ID: 

401 

Type: 

Request 

Status: 

Open 

Opened: 

91/12/05 

Est: 

Closed: 

1 

Pri: 

3 

Sys: 

TOC 

Mod: 

map 

Short: 

Unit  size  designator  should  appear  in  the  middle  of  lines 

Description: 

When  drawing  lines,  unit  size  designator  appears  at  end  of  line,  instead  of 
middle. 

ID: 

406 

Type: 

Request 

Status: 

Open  (deferred) 

Opened: 

91/12/05 

Est: 

Closed: 

5 

Pri: 

2 

Sys: 

TOC 

Mod: 

message 

Short: 

"Draft"  files  should  not  be  visible  from  remote  workstations. 

Description: 

Introduce  the  ability  to  mark  files  and  folders  as  "Work  in  Progress"  files 
or  "Draft"  files  to  prevent  them  from  being  viewed  from  remote  work¬ 
stations. 

ID: 

407 

Type: 

Request 

Status: 

Open 

Opened: 

92/02/21 

Est: 

1 

F-15 


Closed: 

Pri: 

3 

Sys: 

TOC 

Mod: 

map 

Short: 

Quick  access  to  overlay  stack  and  bringing  overlay  to  top. 

Description: 

Change  overlay  top  text  label  to  cascade  button,  picking  button  brings 
overlay  to  top. 

ID: 

408 

Type: 

Request 

Status: 

Open 

Opened: 

92/02/26 

Est: 

Closed: 

1 

Pri: 

3 

Sys: 

TOC 

Mod: 

map 

Short: 

Allow  overlay  functions  in  Edit  Mode. 

Description: 

Allow  user  to  perform  normal  overlay  functions  while  in  edit  mode.  Provide 
user  with  option  for  cancelling,  using  old  or  saving  new  overlays. 

ID: 

409 

Type: 

Request 

Status: 

Open 

Opened: 

92/02/21 

Est: 

Closed: 

1 

Pri: 

3 

Sys: 

TOC 

Mod: 

map 

Short: 

Provide  overlay  "revert”  function. 

Description: 

Allow  user  to  selectively  revert  overlays  to  stored  version  on  disk. 

ID: 

410 

Type: 

Request 

Status: 

Open 

Opened: 

92/02/21 

Est: 

Closed: 

1 

Pri: 

3 

Sys: 

TOC 

Mod: 

map 

Short: 

Provide  selective  overlay  save  screen. 

Description: 

Provide  save  dialog  where  user  is  able  to  pick  any  overlay  and  save  it. 

ID: 

411 

Type: 

Request 

F-16 


Status; 

Open 

Opened; 

92/02/21 

Est; 

Closed: 

1 

Pri: 

3 

Sys: 

TOC 

Mod: 

map 

Short: 

Unit  Size  designators  sometimes  drawn  improperly. 

Description: 

When  a  line  is  first  drawn,  if  the  line  only  has  2  points  or  if  the  unit  size 
designator  is  placed  on  an  acute  angle,  the  designator  is  not  drawn 
completely.  It  is  drawn  properly  if  the  map  is  redrawn. 

ID: 

412 

Type: 

Request 

Status: 

Open 

Opened: 

92/02/21 

Est: 

Closed: 

1 

Pri: 

3 

Sys: 

TOC 

Mod: 

map 

Short: 

Make  Create  popup  easier  to  use. 

Description: 

Possible  warp  cursor  into  text  field  so  user  doesn’t  have  to  move  it  there. 

ID: 

428 

Type: 

request 

Status; 

Open 

Opened; 

92/04/21 

Est: 

Closed: 

2 

Pri: 

2 

Sys: 

BnTOC 

Mod: 

map 

Short: 

Overlays  can  now  be  sent  to  everyone,  not  just  bn  command  net 

Description: 

In  the  past,  overlays  could  only  be  sent  on  the  bn  command  net.  The 
popup  for  sending  overlays  only  allows  this  option.  Now  overlays  can 
and  should  be  allowed  to  be  sent  anywhere.  The  popup  must  change  to 
include  all  routings,  as  well  as  making  sure  the  underlying  code  is  there 
to  handle  overlays  in  the  in-folder. 

ID: 

510 

Type: 

Request 

Status; 

Open 

Opened: 

92/09/15 

Est; 

Closed: 

1 

Pri: 

3 

F-17 


Sys: 

Mod: 

Short: 

Description: 


BnTOC 

tooe 

Provide  label  in  summary  circles 

The  operational  effectiveness  summary  circles  need  appropriate  labels  for 
ammo,  equipment,  fuel,  and  personnel. 


ID: 

Type: 

Status; 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


531 

Request  (BBN) 

Open 

92/09/15 

1 

3 

BnTOC 
Sit  display 

Grey  out  unneeded  map  fimctions 

Desensitize  all  of  the  overlay  and  stacking  functions,  except  show  text  and 
rotation  functions.  The  users  have  gotten  into  the  habit  of  removing 
overlays  posted  to  the  sit  display  from  the  sit  display  itself.  This  has 
caused  problems  with  incongruities  between  the  workstations  and  the  sit 
disp.  Not  allowing  the  users  to  use  the  system  in  this  way  is  probably  the 
most  foolhardy  approach. 


b.  Command  and  Control  Display.  (CCD) 

ID:  316 

Type:  Request 

Status:  Open 

Opened:  91/12/05 

Est:  FS 

Closed; 

Pri:  1 

Sys:  IVIS 

Mod:  rep 

Short:  Provide  preplaiuied  target  option  or  target  reference  points 

Description:  Fire  support  planning  as  outlined  in  FS  TOC  WS  functional  description 

establishes  predesignated  artillery  concentrations  which  are  generally 
numbered  with  two  alpha  characters  and  four  numerals.  These  numbers 
are  usually  assigned  by  the  supporting  artillery.  TRPs  are  usually 
assigned  by  a  unit  which  uses  the  TRP  to  identify  a  specific  location  on 
the  ground  for  orientation  purposes.  Fire  planning,  on  the  other  hand, 
assigns  Concentration  numbers  which  can  be  used  to  call-in  supporting 
fires.  TRPs  may  be  submitted  to  the  FSE  for  addition  to  the  fire  plan.  For 
CVCC  purposes  the  Call  for  Fire  format  should  be  modified  to  permit 
calling  for  fire  either  by  coordinates  or  by  Concentration  Number.  When 
the  format  is  used  when  the  "Where"  field  is  highlighted  the  "Cone  Nr" 
field  should  also  highlight.  An  entry  in  one  field  should  lock  out  the  other 
field.  The  "Cone  Ni "  field  (for  CVCC  purposes)  should  have  the  alpha 
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ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


ID: 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys; 

Mod: 

Short: 

Description: 


ID: 

Type: 

Status: 

Opened; 

Est; 

Closed: 

Pri: 

Sys: 

Mod; 

Short: 

Description: 


prefix  "AB"  entered  as  the  assigned  prefix  for  the  CVCC  supporting 
artillery  designation.  The  standard  keypad  described  previously  should 
be  provided  to  permit  entry  of  the  four  digit  numeric  designation  of  the 
concentration  number.  Further  discussion  is  provided  in  the  FS  TOC  WS 
functional  description. 


324 

Request 

Open 

91/12/05 

refer  to  logistics  mciitik  <  f  the  css  toe 
1 

TOC/TVIS 

rep 

Detailed  logistics  info  should  be  included  in  sit  report 
Need  clarification. 


327 

Request 

Open 

91/12/05 

2 

3 

IVIS 

map 

Provide  location  and  elevation  for  any  point  on  the  map 
ARI  would  like  the  user  to  be  able  to  retrieve  the  location  and  elevation  of 
any  point  on  the  map.  After  discussion  with  ARI,  BBN  can  determine  when 
the  map  will  be  in  a  context  for  this  function. 


333 

Request 

Open 

91/12/05 

2 

3 

IVIS 

map,  menu 

Provide  data  format  options 

Provide  the  following  data  format  options:  a)  mils  versus  degrees;  b)  4-, 
6-,  and  8-  digit  grids;  c)  highlight  or  bold  the  digits  to  show  axis  break 
ES123456. 
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ID:  341 

Type:  Request 

Status:  Open 

Opened:  91/12/05 

Est:  5 

Closed: 

Pri:  3 

Sys:  IVIS 

Mod:  nuq) 

Short:  Provide  alternate  scroll  options 

Description:  ARI  wants  the  following  alternative  scrolling  modes:  a)  in  the  map  menu, 

include  an  input  grid  xxxxxx;  b)  for  incoming  messages  and  overlays,  provide 
center  and  home  fimctions.  BBN  wishes  to  point  out  that  for  option  a,  there 
is  no  con:^)lete  alphanumeric  keypad,  and  for  option  b,  there  is  real  estate 
problems  in  the  show  report  menus.  When  these  issues  are  resolved,  the 
effort  to  implement  the  solutions  will  take  1  person-week. 


ID:  347 

Type:  Request 

Status:  Open 

Opened:  91/12/05 

Est:  10 

Closed: 

Pri:  3 

Sys:  TOC/IVIS 

Mod:  com 

Short:  Provide  system  ack  for  some  messages 

Description:  When  certain  messages  are  received,  ARI  would  like  an  automatic 
acknowledgement  sent  to  the  sender.  This  requires  software  design 
discussion  at  BBN.  This  is  a  signiftcant  change. 


ID:  348 

Type:  Request 

Status:  Open 

Opened:  91/12/05 

Est:  10 

Closed: 

Pri:  3 

Sys:  TOC/IVIS 

Mod:  com,rep 

Short:  Provide  WILCO  key  for  selected  messages 

Description:  For  certain  messages,  a  WILCO  button  should  be  provided.  If  the  soldier 

presses  this  button,  a  message  goes  to  the  sender  of  the  message  which 
indicates  the  soldier  has  read,  understands,  and  will  comply.  This 
requires  software  design  discussion  at  BBN.  This  is  a  significant  change. 


ID:  351 


F-20 


Type: 

Request 

Status; 

Open  (deferred). 

Opened: 

91/12/05 

Est: 

Closed; 

10 

Pri: 

2 

Sys: 

IVIS 

Mod: 

report 

Short; 

Modify/edit  a  received  report 

Description; 

This  changes  the  user  interface  in  IVIS.  A  design  discussion  and  decision 
making  process  will  have  to  take  place  before  this  can  happen. 

ID: 

352 

Type: 

Request 

Status; 

Open 

Opened: 

91/12/05 

Est: 

Closed: 

20 

Pri: 

3 

Sys: 

IVIS 

Mod; 

map 

Short: 

M(^ify/edit  a  received  overlay 

Description; 

In  order  to  do  this,  overlay  editing  capabilities  must  be  added  to  IVIS. 

ID: 

460 

Type: 

request 

Status; 

Open 

Opened: 

92/07/09 

Est; 

Closed: 

2 

Pri: 

3 

Sys: 

IVIS  and  BnTOC 

Mod: 

eff  reports 

Short: 

Adjust  fire  report  not  connected  to  a  eff 

Description: 

There  is  a  eff  report  id  placed  in  the  packet.  It’s  Just  that  nothing  is 
done  with  it  when  the  adjust  fire  rqxirt  is  displayed.  It’s  unknown  what 
should  be  done  with  it. 

ID: 

511 

Type: 

Request 

Status: 

Open 

Opened: 

92/09/15 

Est: 

Closed: 

1 

Pri: 

3 

Sys: 

CCD 

Mod; 

tooe 

F-21 


Short;  Separate  heat  and  sabot 

Description:  Heat  and  sabot  values  should  be  separated  in  the  CCD  ammo  logistics 
reports. 


ID: 

Type: 

Status: 

Opened; 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


519 

Request 

Open 

92/09/15 

1 

3 

CCD 

standalone  mode 

Vehicle  location  should  be  a  setable  parameter 

CCD  own  vehicle  location  should  be  a  setable  parameter  for  the  standalone 
CCD. 


ID: 

524 

Type: 

Request 

Status: 

Open 

Opened: 

92/09/15 

Est: 

1 

Closed: 

Pri; 

1 

Sys: 

CCD 

Mod; 

graphics 

Short: 

CITV  indicator  on  CCD 

Description: 

CITV  indicator  on  CCD 

difficult  to  see 

tank  icon  needs  to  be  dashed  and  longer 


c.  Commander^s  Independent  Thermal  Viewer  (CITY). 


ID: 

Type: 

Status; 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Short: 

Description: 


355 

Request 

Open 

91/12/05 

? 

3 

CITV 

Map  to  sensor  slew 

Allow  the  selection  of  a  point  on  the  m^  which  will,  upon  command,  cause 
the  CITV  head  to  be  laid  on  the  azimuth  from  current  t^  location  to  the 
selected  location. 


ID:  356 

Type:  Request 
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Status: 

Opened; 

Est; 

Closed: 

Pri: 

Sys: 

Short; 

Description: 


ID: 

Type: 

Status; 

Opened; 

Est; 

Closed: 

Pri: 

Sys: 

Short: 

Description: 


ID: 

Type; 

Status: 

Opened: 

Est: 

Closed; 

Pri: 

Sys: 

Short: 

Description: 


ID: 

Type: 

Status: 

Opened: 

Est; 

Closed; 

Pri: 

Sys: 

Short; 

Description; 


Open 

91/12/05 

? 

3 

CITY 

Dedicated  function  switch  with  CITY  integration 


357 

Request 

Open 

91/12/05 

? 

3 

CITY 

Depict  lase  azimuth/range  graphically,  range  digitally  on  CCD 
When  lasing  to  a  target  (or  terrain  location)  display  a  ray  from  own  tank 
icon  on  the  CCD  to  the  target  and  display  the  range  digitally  beside  the 
ray.  Maintain  on  the  CCD  for  20  sec.  duration,  then  erase. 


358 

Request 

Open 

91/12/05 

? 

3 

CITY 

Set  auto  scan  sector  using  CCD  map 

Provide  a  mechanism  for  setting  CITY  scan  limits  by  selecting  R  &  L  sector 
limits  on  the  CCD. 


359 

Request 

Opra 

91/12/05 

? 

3 

CITY 

Ability  to  transmit  fire  sectors  to  coordinate  fire  plans 

Using  a  mechanism  similar  to  the  scan  limit  sector  set  (See  ID;  358)  allow 

tank  cmdrs  to  transmit  primary  fire  sectors. 
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ID: 

Type- 

Status: 

Opened: 

Est: 

Closed; 

Pri: 

Sys: 

Short: 

Description: 


360 

Request 

Open 

91/12/05 

? 

3 

CITY 

Set  CITY  Auto  Scan  sectors  relative  to  current  tank  position 
Provide  ability  to  set  CITY  Auto  Scan  sectors  according  to  your  tank  (e.g., 
over  the  front  or  rear  fenders,  etc.)  in  addition  to  setting  according  to 
direction. 


d.  Semi-Automated  Forces  (SAPOR). 


ID; 

Type: 

Status: 

Opened: 

Est: 

Closed; 

Pri: 

Sys: 

Short: 

Description: 


375 

Request 

Open 

91/12/05 

1 

I 

SAP 

Need  global  commands  available 

Need  global  commands  available  (E.g.,  stop  all  units  with  single  command). 


ID:  376 

Type:  Request 

Status:  Open 

Opened;  91/12/05 

Est:  2 

Closed: 

Pri:  1 

Sys:  SAP 

Short;  Need  ability  to  "Scroll  Lock"  the  report  log  window 

Description:  Need  ability  to  "Scroll  Lock"  the  report  log  window  to  allow  SAPOR 

operators  to  read  reports. 


ID; 

Type: 

Status: 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Short: 


393 

Request 

Open 

91/12/05 

15 

3 

SAP 

RESUME  to  the  nearest  point  on  original  route  after  TAC/E 
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Description;  When  a  unit  executing  a  rout  has  been  given  TAC/E  commands  taking  it  off 
the  route,  and  is  then  told  to  "Resume",  the  unit  should  go  to  the  nearest 
point  on  the  route  and  continue  from  there,  rather  than  from  where  the  route 
was  left. 


g,  STO  UUiitY. 


ID: 

Type: 

Status; 

Opened: 

Est: 

Closed: 

Pri: 

Sys: 

Mod: 

Short: 

Description: 


517 

Request 

Open 

92/09/15 

1 

3 

send 

vignettes 

Want  to  specify  network  by  report 

CVCC-Send  reports  placed  within  vignette  files  cannot  be  sent  on 
different  nets.  BDM  desires  this  feature. 
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